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大几倍。

巴特西

VU TPS QPS RT 计算公式

1.背景

2.验证

3.QPS与TPS引发的问题

最新文章

热门文章