VU TPS QPS RT 计算公式

1.背景

    最近看了阿里巴巴中间件写的一篇文章，讲述了关于并发，RPS，RT之间的关系。感受收获颇丰。本身使用JMeter工具对公式进行了验证。

2.验证

咱们先来看几个基础知识定义：

1. TPS：每秒完成的事务数。
2. QPS：每秒发送的请求数（同RPS）。
3. RT:交易响应时间。
4. 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大几倍。