测量、基线和性能优化之三：基于测量、基线和变化的性能优化

        我们建立了可测量的指标，为可测量的指标建立了基线，确立了基于变化的性能优化诊断理论，性能优化诊断就成为水到渠成的事情了，而通过可测量指标的相关性分析就可以轻松的对于性能进行改善，从而完成性能优化工作。
         回到我们的吞吐量曲线基本图：
        
        我们采用最简单的模型来进行基于变化的性能优化实践

         吞吐量：= （ 60/响应时间 ） * 并发Session数量
         响应时间：= 服务处理时间 + 服务排队（等待）时间
         服务处理时间：= 单元服务次数 * 单元服务时间  
         服务等待时间：= 单元服务次数 * 单元服务等待时间
                                 ：= IO等待次数*IO等待时间 + 并发性等待次数*并发性等待时间 + 其他等待次数 * 其他等待时间

         可测量的基线指标（峰值）：
         响应时间：=1560ms
         并发数：    =100
         吞吐量：    = 3846
         服务处理时间：=  3894秒
         单元服务次数：=  9500
         单元服务时间：=  410ms
         服务等待时间：=  2096秒
         单元服务等待时间：= 220ms
         IO等待次数：=100
         IO等待时间：=2ms
         并发性等待次数：=2000
         并发性等待时间：=0.01ms
         其他等待次数：= 0
        
         发生性能问题之后以上可测量的指标观察到：
         响应时间：=5000ms
         并发数：    =250
         吞吐量：    = 3000
         服务处理时间：=  3750秒
         单元服务次数：=  7421
         单元服务时间：=  505ms
         服务等待时间：=  11250秒
         单元服务等待时间：= 1516ms
         IO等待次数：=78
         IO等待时间：=20ms
         并发性等待次数：=1560
         并发性等待时间：=0.01ms
         其他等待次数：= 0
       
         通过以上可测量指标的简单比较可以发现：响应时间增加，并发数增加，吞吐量下跌。进一步比较可以发现响应时间增加主要原因为单元服务等待时间从220ms增加到了1516ms，单元服务时间略有增加。而单元服务等待时间的增加主要是由于单元IO等待时间的变化引起，从2ms增加到了20ms。通过和基线指标数据的变化比较可以很简单作出诊断：IO子系统出现问题导致响应时间增加，而通过我们对于IO子系统的知识储备可以知道20ms的响应只有两种可能性：（1）、IO严重堵塞  （2）、IO子系统出现故障类事件（配置或者其他）。从IO发生次数可以知道，严重堵塞的可能性不大（并非绝对没有，比如很多数据库外的负载），我们的调整方向就走向IO子系统故障，检查其配置和状态，检查其IO子系统组成链路。
        这个时候我们可以进一步检测磁盘系统的基线：
        磁盘利用率：=98%
        iops:= 3600
        服务响应时间：= 2ms

        各位读者可以想象一下，如果缺乏基线数据，相当多的优化工作者可能会通过调整SQL语句降低IO数量来完成本次优化。

        
            

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/92650/viewspace-774839/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/92650/viewspace-774839/