性能度量的建立-让性能bug诊断更简单
相信本文会对处于下面两种状态的测试工程师朋友会有所启发和帮助1. 正要但还没开始做性能测试的朋友，除了loadrunner，不知道从哪里下手
2. 已经开始做性能测试，正在被一堆问题困扰得焦头烂额的朋友。
听说过有的工程师运行几轮性能测试，就能迅速定位性能bug；更多地是听到某工程师运行N多次，就是不能复现问题，甚至整个研发部门开发人员测试人员齐上阵，都无法找到性能问题所在。这是为什么呢？是运气不好么？还是技术能力不强？
说说我看过的一个真实的案例：某大型外企的产品上线后，当用户数超过某个值的时候，在线的软件系统就会重启。这是一个严重的bug，但非常糟糕的是，在测试环境里，测试人员无论如何，都复现不出这个bug，研发部门的老总调用了精兵强将，包括众多开发骨干，苦苦搜索一个多月，也都无终而归，最后的结果是企业最终失去了这个大客户。其实这样一个大型系统，面对这种问题，别说开发人员，就是比尔盖茨来了，也无济于事。
显然这不是技术能力范畴内能解决的困境，怎样使得性能诊断变得更加容易和方便？这其实是一个软件开发要考虑的可测试性问题。
对于性能测试来说，有必要在软件设计开发阶段遵守规范，建立一整套性能度量体系。体系包括
1. 性能诊断日志
2. 在应用系统层次上建立性能度量
3. 数据库系统性能度量
性能诊断log包括一系列log等级设置和log格式，使得性能问题能够在log层次上被捕捉到，比如下面是一个SMPP协议网关实现的log
TimeStatistic --------
Statistic name : EnquireLength
Description : Time taken for a round trip ENQUIRE_LINK PDU.
Measurement unit : MILLISECOND
Measurement start time : 1224214074885
Last measurement time : 1224219511193
# times the operation was invoked: 3
max time : 19
min time : 12
total time : 46
在性能诊断模式开启后，软件程序就会每隔10秒钟打印如上信息，从以上信息可以很清楚地看到SMPP网管处理多少个PDU，每个PDU花了多长时间。这样会第一时间内捕获网管的性能处理效率。
在应用层次上的度量多种多样，根据应用的不同，也有不同的度量方法。比如我们最常见的web 处理能力一般用每秒请求数（requests/second),每秒吞吐量（throughoutputs/second)。其实针对每一个应用，开发人员都应该建立相应的度量。
比如一个email 的IMAP server，我们为其建立如下度量
APPEND Average Time (milliseconds)
APPEND Failure Rate (Failures/minute)
APPEND Rate (Requests/minute)
AUTHENTICATE Average Time (milliseconds)
AUTHENTICATE Failure Rate (Failures/minute)
等等。
一般地，度量要分为度量名，采集频率，预警值设置，预警信息等等。
开发人员则遵循规范，在开发过程中实现以上度量信息的采集。
在建立一个完善的性能度量体系后，性能的诊断和定位就变得更加容易，也完成了定性分析到定量分析的转变。
（有兴趣的朋友可以参看oracle的AWR报告，这是一个典型的基于度量的report） 说实在话，不是太明白.
在日常工作中，如果性能测试未能发现而实际出现错误的时候,一般会抓取详细的中间件\OS\DB\软件系统的相关详细日志用于分析,可基本定位问题点,然后根据实际情况做相应测试去重现,这些过程一般会迭代多次,基本可以细化到具体. 一个性能诊断性良好的软件系统一定要通过日志或度量的方式给软件人员留下尽可能多的性能信息。
想想我们常用的性能测试瓶颈方法，如排除法，隔离法等等，通过运行不同场景，来判断哪个节点出了问题，在本质上都是黑盒测试，因为节点里的信息不够完整或透明。如果我们获得足够多的信息，完全可以一次运行，就能定位问题。
中间件/DB/OS都提供了如oracle的top sql，MQ的message queue等度量，为什么我们的开发人员不能在开发应用程序的同时，也建立这样的度量接口呢？ 实际上，应该在产品设计开发阶段，就要建立相应的日志规范和编码规范。 呵呵，其实一些大型成熟的软件企业在开发团队内都有一套度量和日志规范。 说的很对。特别是对产品。
页:
[1]
