文章转自：原创： 杨建旭 https://mp.weixin.qq.com/s/Y2pE6wDTJ0bma0DXOBTC0g
在实际的生产运行、测试过程中，一般都会关注吞吐量、响应时间、CPU利用率，在开发和测试阶段，我们不但需要关注，而且要通过它们之间的关系来验证测试的结果是否可信、分析性能问题在哪里。
这里先举一个例子，通过计算，发现测试结果不可信的例子。
该场景是服务器并发处理业务报文，并且达到了最大处理能力（即TPS达到最大，如果再增加压力，就出现拥堵现象），性能测试结果如下
看了之后结果，我立刻说：这不可能
原因如下：这个场景中TPS=14，一共有20个进程并发处理。那么每个进程每秒钟处理的业务个数=14/20=0.7个。
那么每个业务的响应时间（理论计算）=1（秒）/0.7=1.43秒。
而测试结果显示，业务响应时间为240毫秒（0.24秒），这中间的1.42-0.24秒哪里去了？这个结果一定不可信。随即，我咨询对于响应时间的统计方式。得到的答复是：统计工具从日志里面统计的。好吧，只能打开原始日志看了。
原始日志中每个业务有5个时间戳，我姑且叫它们ABCDE吧。
A：客户端发起的时间（按照客户端的机器时间给打的时间戳）
B：服务器端进程从消息中间件中取出消息的时间
C：服务器端开始处理的时间
D：进程认为自己处理结束的时间
E：写这一条日志的时间
当前的统计方式是D-C。
问：为什么不是E-B？
答：开发人员说按照D-C
好吧，不扯那么多了，计算吧。
计算几万条业务的E-B的平均时间，1573.34毫秒，和我们理论的计算（1.43秒）基本吻合。
所以，之前的统计方法是错误的。
举第二个例子，和CPU利用率相关的例子。
这个例子中，同样是服务器并发处理某类业务报文，性能测试结果如下：
平均响应时间是198.78毫秒，即0.19878秒。那么每个进程每秒钟处理的业务个数=1/0.19878=5个。
服务器一共设置了最大20个进程并发处理。那么如果这20个进程都被调用起来全速处理的话，它们的最大处理能力是每秒钟=20*5=100个。
而当前的TPS=52.46，相当于最大能力（100）的52.46%，那么CPU利用率也应该差不多这个数，我们实测的CPU利用率是56%，考虑随着TPS的增加，业务响应时间也是会变化的，系统的CPU也不是完全线性变化的，上述的计算推测已经是非常吻合实际情况了。说明这个测试当中，各个系统性能数据之间是可以从数字关系上对上号，说明他们的取值都是正确的。
这里还要多说一点，在虚拟化环境下，大多数人对AIX/Power系统的CPU利用率取值是错误的，因此拿起测试结果大致一算，是对CPU利用率取值的快速验证。虚拟化环境下Power系统的CPU利用率取值我在之前的文章中有过介绍，感兴趣的同学可以回看。
