吞吐量响应时间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利用率取值我在之前的文章中有过介绍,感兴趣的同学可以回看。

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180123G0NYUE00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券