VU TPS QPS RT 计算公式
1.背景
最近看了阿里巴巴中间件写的一篇文章,讲述了关于并发,RPS,RT之间的关系。感觉收获颇丰。自己使用JMeter工具对公式进行了验证。
2.验证
我们先来看几个基础知识定义:
- TPS:每秒完成的事务数。
- QPS:每秒发送的请求数(同RPS)。
- RT:交易响应时间。
- VU虚拟用户数(VU是LR中的叫法,对应JMeter里的线程数)
针对以上术语定义,相信大家早已耳濡目染。唯一需要强调的是TPS(可以包含1到N个请求),本文均以一个请求来进行测试验证。
Little定律公式:并发用户数 = QPS x RT
- 测试脚本结构图:
说明:JMeter版本5.1.1,采用JMeter自带Java请求(JavaTest),将Sleep_Time设置为1。
- 线程组设为100并发,运行10秒中,测试结果如下:
套用公式:并发数=701.3291634089131 x 0.133 = 93.276778679 ,与预期并发数(100)相差较大。初步怀疑是样本数太少,导致偏差较大。
- 线程组设为100并发,运行30秒中,测试结果如下:
套用公式:并发数=752.193926548995 x 0.129 = 97.033016524692 ,与预期并发数(100)还是有点差距。初步验证怀疑是正确的。
- 线程组设为100并发,运行180秒中,测试结果如下:
套用公式:并发数=789.7479728492222 x 0.126 = 99.508244579002,与预期并发数(100)基本一致。考虑到性能消耗,可以认定公式的正确性(假象下如果此场景运行无限长时间,那么可以推测出:吞吐量 x 平均响应时间的值无限接近线程组设定的并发值)。
3.QPS与TPS引发的问题
我们再来验证个有趣的问题:
由此图可以推算出:ART为126ms,也就是1s能发送大约7.9365个请求,100并发1秒能发出约:793.650个请求,也就是QPS=793.650笔/秒,与图中吞吐量的值几乎一致。可以看作:当前QPS与吞吐量值相等,而此时的吞吐量可以看成TPS。
我们改动下脚本:
说明:增加了QPS控制器
我们再次执行,结果如下:
笔者脚本中限制了:最大QPS为200,此时吞吐量约为198.682,两者基本一致,进而验证了(笔者感觉导致误差的原因在于:场景启动时需要一个warm up 过程,不能在启动场景的瞬间就达到限制的200QPS)。笔者将脚本中的JAVA请求换成本地HTTP请求,测出的现象均一致,由于篇幅限制就不再赘述。
此时再用老套路计算下QPS,平均响应时间为127ms,推算出1s能发送7.87401笔,100并发能发送787.401笔,我擦了,为啥与预期200笔差距这么大?
注意:这种方式计算出的值只是理论值,因为笔者脚本中已经设置了200QPS限制,并不限制请求的RT(换句话说只限制了单位时间内发送的请求量,再或者可以理解成限流)
结论:单独对QPS与TPS进行对比是没有意义的,他们是不同的衡量指标。在真实的环境下往往一个事务包含多个请求(即多个请求组成一个事务),此时再比较两者,会发现QPS要比TPS大几倍。