今天，我的一个学生发来一个问题，说有个性能需求，要求接口满足20qps，然后，他就使用了一个叫“常数吞吐量定时器”的，设置目标吞吐量为1200.0每分钟。
结果执行完测试，看聚合报告中的数据，吞吐量是一个不确定的数字，这就给整懵了。问我这东西怎么用？
其实，要弄明白常数吞吐量定时器的用法，最关键的地方是【基于计算吞吐量】的选择。有五个枚举值。
先来看我设计的一个脚本，一个普通线程组，添加一个‘常数吞吐量定时器’ 和 ‘调试取样器’ 和 ‘聚合报告’，用调试取样器，模拟接口取样器。
接下来，我们看下，用50线程数和100线程数，持续运行60秒钟，分别选择不同的【基于计算吞吐量】，聚合报告中的数据汇总。
是不是整懵圈了，使用默认的‘只有此线程’时，线程数不同，总样本差异很大，吞吐量差异也大。而最后面两个，线程数变了，但是总样本和吞吐量都不变。
这是什么意思呢？
为了解释，为什么前面三个会有差异，我们再来做两组实验。
第一组实验：测试计划只有一个线程组，常数吞吐量定时器，放在线程组中。
实验场景：在取样器的名称后面，增加一个${__threadNum}线程号函数，这样，在聚合报告中，就能看到对应的每个线程，在60秒钟内的数。
- 基于计算吞吐量：只有此线程
‘只有此线程’，就是每个线程，都会朝着目标吞吐量调整请求频率，最终期望每个线程，都能达到‘目标吞吐量’。当然，这个过程中，也会出现，每个线程的请求次数是不相等的，所以，就出现了如上图，每个线程的吞吐量是20，但是总样本存在一定差异，但是，样本÷时长≈吞吐量。
所以，使用默认的‘只有此线程’，向被测服务器发起请求，实际对服务器造成的压力，是你设置的‘目标吞吐量’值×线程数，远大于你期望的。如果遇到性能瓶颈，那这个公式的结果就是一个不确定值了。
- 基于计算吞吐量：所有活动线程
所有活动线程，常数吞吐量定时器，放在线程组中，就是控制当前线程组下所有的活跃线程数，对服务器控制被测服务器受到的请求压力为‘目标吞吐量’，但是，每个线程都是各跑各的，所以，就出现，总体吞吐量约为设置的目标吞吐量值，但实际每个线程请求的次数可能不相等，
- 基于计算吞吐量：当前线程组中所有活动线程
这个和一种是相同的，因为，此时常数吞吐量定时器，放在线程组中。因此，我们看到的数据，几乎相同。
- 基于计算吞吐量：所有活动线程(共享)
相比第2个多了个‘共享’，就是所有活动线程作为一个整体，整体的目标是‘目标吞吐量’，这样，不管线程数是多少，都是一个整体，聚合报告中看到的总样本数都是一样的，吞吐量就是‘目标吞吐量’设置的值。
- 基于计算吞吐量：当前线程组中所有活动线程(共享)
与第3个相比，多了个‘共享’，就是当前线程组中所有活动线程为一个整体。不管你设置多少线程数，都控制整体发起的请求，对被测系统造成的压力是‘目标吞吐量’设置的值。
第4、5种，都是把活动线程当作一个整体，控制整体对服务器造成的压力。所以，测试结果两者的总样本数比较接近，吞吐量也更近视等于目标吞吐量。那他们的差异会在哪呢？我们再看第二组实验。
第二组实验：测试计划下有多个线程组，常数吞吐量定时器，放在测试计划下。
实验场景：一个测试计划下有多个线程组，而且，每个线程组的线程数和持续运行时间可能不同，‘常数吞吐量定时器’放在测试计划下面。
- 基于计算吞吐量：只有此线程
每个线程组的线程执行的请求数，可能存在差异，但是，整体控制每个线程的吞吐量都约等于目标吞吐量，最终的总体吞吐量的值，其实是一个不容易计算出来的值。
- 基于计算吞吐量：所有活动线程
多个线程组，每个线程组的线程数和执行时长有差异，‘所有活动线程’控制整个测试计划下的所有线程组中的活动线程，使
- 基于计算吞吐量：当前线程组中所有活动线程
因为有多个线程组，所以，这个当前线程组，其实是每个线程组中活动线程。因为多个线程组，每个线程组的场景设计不同，其实，最终测试的结果差异非常大，一般，是不能直接确定吞吐量值的。
- 基于计算吞吐量：所有活动线程(共享)
这个没有线程组之间的差异，测试计划下所有线程组的所有线程一起，控制对被测服务器发起的请求为设置的‘目标吞吐量’。所以，选择这个，不管是一个线程组，还是多个线程组，最终的吞吐量都是比较接近‘目标吞吐量’的。
- 基于计算吞吐量：当前线程组中所有活动线程(共享)
多个线程组，一起共同遵循目标吞吐量的设置，但是，多个线程组的线程数和持续运行时长，会有差异，这样，也就导致结果数据不一定等于设置的目标吞吐量的值。
结论
想要用常数吞吐量定时器来人为的控制JMeter向被测服务器发起的请求压力，更多时候，我们应该选择第4个‘基于计算吞吐量：所有活动线程(共享)’