简单说说系统优化（2）响应时间模型

做数据库性能优化之前，我们必须了解数据库性能相关的主要因素，因为数据库是一个极其复杂的软件系统，数据库性能优化也是一个十分复杂的系统性工程。我们该如何评估一个系统的性能，以及我们该如何判断系统性能问题的关键要素是数据库性能优化的基础。从总体来说，描述数据库性能的最佳指标是响应时间。

为了更好的理解数据库性能优化评价体系中的这个最核心的问题，首先我们必须搞清楚响应时间的含义，因为响应时间实际上也是一个十分复杂的评价标准体系。我们是选取最大响应时间、最小响应时间、平均响应时间还是90分位响应时间作为评价性能好坏的依据？另外我们讨论的响应时间是针对某个具体的应用的，还是系统总体的平均响应时间，还是长时间执行SQL的平均响应时间呢？

一般情况下，在选择响应时间的评估值的时候，平均响应时间和90分位响应时间具有一定的参考价值，特别是90分位指标，而最低和最高响应时间的参考意义并不大。可能有些读者对90分位值的概念比较陌生，90分位值是指把在某个采样周期内的响应时间按照从低到高排序，排在90%位置的响应时间数值就是响应时间的90分位值，对于所有的监控指标我们都可以采用此种方式来获得90分位值。

一般情况下，在较高并发的系统中，响应时间的波动是比较大的，最大和最小值可能相差数倍甚至几十倍，我们在做分析的时候使用哪个值来做评估呢？如果我们认为业务系统中的90%的响应时间应该处于正常范围，那么我们只需要看90分位值的大小，如果90分位值处于合理范围，那么我们就认为系统响应时间是满足用户要求的。如果90分位值超出了用户能够忍受的范围，那么说明目前系统的响应时间超出了用户要求的范围。实际上，对于不同的用户需求，我们可以选择90分位，也可以选择95分位，或者80分位的指标来做分析与判断。

而对于选取哪个应用模块的响应时间问题上，根据你的系统的特点不同，可以选择不同的策略。如果数据库系统上的应用十分稳定，每天的某个具体时段的应用模块的特点以及并发量都差不多，那么数据库总的平均响应时间（比如SQL平均执行时间）就可以作为评估参考。如果你无法掌握这些情况，或者系统中的SQL语句，执行频率等相差很大，那么你应该根据业务部门关心的各个种类的典型SQL去确定一张关键SQL响应时间清单。根据清单上的这些关键SQL的响应时间来判断数据库的总体性能情况。

获得了响应时间的相关信息后，我们就可以进行下一步分析了。在分析之前，我们首先要了解一下数据库系统的响应时间模型，这个模型对于后续的优化工作具有十分重要的指导意义。

上图是十分著名的响应时间模型的逻辑概念图，随着每毫秒并发事务数的增加，平均事务响应时间的指标也会随之加大。刚刚开始的时候，随着并发事务的加大，响应时间可能并不会增加，这种情况是在各个并发事务并无争用，系统的负载也较低，不会产生系统资源、锁等的争用的前提下产生的。而随着并发量的加大，响应时间也会缓慢增加，这种增加是接近线性的。而当并发量超过一定阈值的时候（这个图上大约是1.55trx/ms），响应时间增加的幅度会突然变大，这是因为某种资源或者锁出现了严重等待，产生了一定的瓶颈。在这个点之前的所有监控指标数据对于发现系统问题的意义都不是很大，而这个时间点之后的指标数据，特别是这个点前后的数据，对于定位系统瓶颈就更为关键了。这个点的发现对于我们进行数据库性能优化十分关键。

另外大家可以从这个模型中看出，响应时间由两部分组成，服务时间和等待时间。其中的服务时间是完成该服务（对于数据库系统来说，就是执行该SQL或者存储过程等）所需要的各种计算固有消耗的时间。等待时间是因为并发访问而产生的各种等待的总和，这个时间随着并发量的不断增加而增加，并且在某个拐点之后会出现加速增长的趋势。

针对PostgreSQL数据库而言，服务时间就是SQL语句完成所需要的固有时间，数据库系统中没有并发事务时执行SQL语句，并且当前系统资源对于该SQL语句不存在瓶颈时所需要的时间接近于这个时间。这句话似乎有点绕，因为这里面包含了一个特例，就是某个单一SQL也可能会导致某个数据库系统的资源出现了某方面的瓶颈，从而导致SQL单独执行时就存在大量的等待时间，因此我们只能说比较接近。要想减少服务时间，我们就必须通过SQL优化来减少SQL本身的开销（比如语法改写，优化执行计划等），当然如果我们能够减少SQL访问的数据量（比如采用数据归档、分区表、做表碎片整理、重建索引等方式减少某条SQL扫描的数据量）也可以有效的减少服务时间。

减少等待时间就更为复杂了，我们可以看到，当并发量不是很高的时候，等待时间是很小的，而当并发量到达一个拐点的时候，等待时间会急剧增长。通过SQL优化，让系统能够承受更大的并发执行数量，可以让拐点出现的更晚，这样就可以有效的降低等待时间。

除了上面的两种优化途径外，我们还可以通过流控、系统排队等应用软件架构上的优化方案，让系统高峰期的每毫秒并发事务量得到有效的控制，这样就可以通过控制流入PostgreSQL数据库的并发执行的SQL总数来缓解数据库的压力，从而降低数据库的事务响应时间。这种流控模式会增加前端排队的等待时间，不过可以有效的降低数据库的等待时间。当数据库并发处理能力遇到瓶颈，暂时没有其他方法解决的时候，前端流控可能是比较好的方案。不过我们对此种优化方案，需要做全面的评估，如果在流控上产生的业务等待时间是可接受的，那么此方案是有效的，反之这个方案在此场景中就不可用。有些时候，优化团队为了简化应用，在做流控时并不采用加大排队的方式，而是采用直接丢弃超出处理能力的访问请求。如果我们的前端应用没有做好响应的控制，并且具有持续地反复重试地功能，那么这种流控方法会导致前端不断地重发响应地请求，最终导致前端地IT基础设施出现瓶颈，从而导致更为严重地性能问题。因此我们在做这方面优化工作的时候，一定要对应用架构有十分深入地理解。

另外要说明的是，如果我们优化了系统中并发执行较多的SQL，那么总的资源开销就会下降，那么资源争用也会降低，响应时间模型的形态也会发生改变，这也是SQL优化往往能够起到立竿见影的效果的原因。

响应时间模型是做系统优化，特别是数据库优化的十分基础的模型，理解响应时间模型有助于在数据库优化的时候做出合理的决策，采用适当的手段来完成优化工作，实现优化目标。事实上，数据库优化的复杂度远大于上面所说的集中情况，对于不同类型的应用系统，我们采取的措施也会不同。如果我们能够在研发阶段控制SQL的质量，对于新上线的SQL进行审计分析，避免存在性能问题的SQL上线，那么我们可以十分有效的管控生产系统的性能。如果对于一个系统变更十分频繁的系统，而我们无法常态化的进行SQL优化，那么仅仅通过SQL优化就很难保持优化效果的有效性。在数据库优化工作中，我们也往往无法通过单一的手段来实现我们的优化目标，在大多数情况下，采用“鸡尾酒疗法”才能解决数据库的性能问题。