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