11.1.2 度量方式
有了度量数据后,我们将采用不同的方式对其进行分析,来达到性能度量的目的。
1.使用下钻细分法进行瓶颈定位
我们用层层下钻的方式来进行性能的定量分析
一级下钻
某交易的系统响应时间=客户端处理时间+网络时间+Web服务器时间+应用处理时间+数据库时间
案例分析
例子:比如某邮件系统的Web发送邮件的总共耗费时间为4秒,根据度量数据,进行一级下钻:
● 客户端处理时间:浏览器处理时间,忽略
● 网络响应时间:54ms,相比15S,可以忽略
● Web服务器时间:0.56S/Http Request
● SMTP服务邮件发送处理时间:未知
● 数据库处理时间:connect time+Sql parse time+ sql execute time=1.4S
总响应时间=页面时间+网络时间+Web处理时间+SMTP邮件服务处理时间+数据库处理时间
4S=0+0+0.56+ SMTP应用服务时间+1.4
SMTP应用服务时间=40.561.4≈2S
二级下钻
下面,尝试将SMTP服务时间进一步下钻细分。
SMTP服务架构如图11-1所示。
图11-1 SMTP Service Architecture
大致可把SMTP处理分为几个阶段:
SMTP服务时间=认证时间+SMTP Local Queue入队时间+Outbound处理时间
在各个模块上进行监测,时间细分为2S≈0.02S+1.2S+0.7S。
由于Job Queue上花费了1.2S,那么说明邮件队列还有调优的空间。
2.使用正交图来预测性能拐点
两个因素A和B,B的变化会导致A的变化,那么可以以A为纵轴,B为横轴,建立二维正交图来观察A和B之间的影响作用大小及发展趋势。
比如在上面的基准环境度量数据例子中,A为性能响应时间,B为基础容量数据,以upload file测试案例为例,可以绘制如图11-2所示的曲线图。
图11-2 容量—性能变化曲线
从以上曲线可知,随着数据容量的增加,性能响应时间增加幅度较少,这是一个斜率小于1的曲线,因此,可以预测在将来容量增加的一段时间内,应该不会存在容量拐点和瓶颈。
在上面的周期迭加度量数据例子中,A为性能时间,而B为版本周期。以download file测试案例为例,可以绘制如图11-3所示的曲线图。
上面的曲线反映了一个问题,第二个版本相比第一个版本出现了较大幅度的性能衰退,而在第三个版本和第四个版本中得到解决,并加以控制。
图11-3 版本—性能变化曲线
总结
数据是性能量化分析最重要的基础和前提。要想做到量化分析,需要在不同的时间和空间内重复执行性能测试,并收集详细而全面的度量数据。在某种程度上来说,没有采集度量数据的性能测试是毫无意义的。
案例分析 性能bug定量分析实际案例
Bug标题:1.1版本升级到1.2后login action发生40%的性能衰减。
测试环境:某Web订票系统1.2版本。
场景描述:50用户ramp并发login运行一个小时,thinktime 500毫秒。
测试结果:1.2版本Login Service花费时间为4.2秒,而1.1版本同样的场景案例则花费2.4秒。
对1.2版本上采集的性能度量数据进行下钻细分,Oracle DB的AWR TOP SQL report捕捉到一条sql语句耗时达1.5秒。
select username,password from ocs_data.auth_users where NLSSORT(username,'NLS_SORT=GENERIC_M_CI') = NLSSORT('ocsadmin', 'NLS_SORT=GENERIC_M_CI')
对比1.1版本的AWR Report,发现这是一条1.2版本新引入的sql语句。1.1版本同样作用的sql语句为:
select username,password from ocs_data.auth_users where username= 'ocsadmin'
耗时仅为50毫秒。
解决建议:
新sql语句耗时时间较长,是由于where使用了新的字段表达式,而使得原有的字段索引没有排上用场。建议建立新的字段索引。
Bug总结:
上面的bug分析逻辑清楚,直接揭示瓶颈根源,定位到了语句级别。能完成这样的量化分析,依赖于以下几个基础条件:
● 节点数据采集点详细而全面,在oracle DB上使用awr 进行sql语句采集,这为sql语句性能分析提供了数据基础。
● 周期数据持续采集形成对比基准。在1.1和1.2版本中持续进行性能回归测试,直接将新旧版本上top sql进行对比,这为瓶颈定位提供了逻辑条件。