吞吐量响应时间CPU利用率之间的关系

在实际的生产运行、测试过程中，一般都会关注吞吐量、响应时间、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利用率取值我在之前的文章中有过介绍，感兴趣的同学可以回看。