浅谈逻辑控制器之吞吐量控制器

吞吐量控制器（Throughput Controller）作为JMeter逻辑控制器之一，旨在帮助测试工程师控制测试脚本中各个部分的执行频率或次数，以模拟特定的业务流量分布。

吞吐量控制器概述

吞吐量控制器并不直接控制系统的吞吐量，而是控制其下挂载的采样器（Sampler）或控制器的执行比例或次数。这使得测试人员能够根据业务需求，为不同的请求分配不同的执行权重，从而模拟复杂多变的真实用户访问模式。

工作原理与配置

吞吐量控制器提供了两种控制模式：

1. 百分比（Percent Executions）：在此模式下，吞吐量控制器会基于配置的百分比来决定其下元件的执行次数。例如，如果设置为20%，则在测试执行期间，该控制器下的请求将只被执行所有请求总次数的20%。
2. 总执行次数（Total Executions）：这种模式允许你直接指定控制器下元件的总执行次数，无论测试运行多久，达到设定的执行次数后，该控制器下的采样器将不再执行。

配置步骤：

1. 在JMeter中创建或打开一个线程组(Thread Group)。
2. 右键线程组，选择“添加” -> “逻辑控制器” -> “吞吐量控制器”。
3. 为吞吐量控制器命名，并选择合适的控制模式（百分比或总执行次数）。
4. 根据选择的模式，输入相应的数值。
5. 将需要控制执行频率的采样器或子控制器拖放到吞吐量控制器下。

应用实例

我们编写如下脚本

线程组：线程数设置为10，其它保持默认
BeanShell 取样器1：编写如下脚本

log.info("test1");

BeanShell 取样器2：编写如下脚本

log.info("test2");

情况1：吞吐量控制器选择Total Executions，其他默认

分别将吞吐量控制器1和吞吐量控制器2的吞吐量设置为7和3，运行脚本，查看聚合报告

通过聚合报告可以发现，运行的线程数根据设置的内容进行执行，此时如果线程组数调整为10+，统计的线程也会是控制在7和3。

情况2：吞吐量控制器选择Percent Executions，其他默认

分别将吞吐量控制器1和吞吐量控制器2的吞吐量设置为80和20，运行脚本，查看聚合报告

通过聚合报告可以发现，运行的线程数根据设置的百分比分配，BeanShell 取样器1对应的吞吐量为80，所以执行的线程数为10 * 80% = 8，根据同样算法可以得到BeanShell 取样器2线程数为2。

情况3：吞吐量控制器选择Total Executions和Percent Executions混合

线程组：线程数设置为100，其它保持默认

假设1：

吞吐量控制器1：选择Percent Executions，吞吐量设置为50，不勾选Per User
吞吐量控制器2：选择Total Executions，吞吐量设置为20，不勾选Per User
运行脚本，查看聚合报告如下：

根据情况1和情况2 ，不难算出上述的数据是如何得来。

假设2：

吞吐量控制器1：选择Percent Executions，吞吐量设置为50，勾选Per User
吞吐量控制器2：选择Total Executions，吞吐量设置为20，不勾选Per User
运行脚本，查看聚合报告如下：

上述结果可以看出，如果吞吐量控制器1勾选Per User，但是吞吐量设置不空或者不是100，此时吞吐量控制器1数据上产生了矛盾，JMeter不知道需要哪个数据，所以BeanShell 取样器1没有执行，大家可以尝试当吞吐量设置为100或者空时并且勾选Per User时，BeanShell 取样器1线程数等于线程组的线程数

假设3：

吞吐量控制器1：选择Percent Executions，吞吐量设置为50，不勾选Per User
吞吐量控制器2：选择Total Executions，吞吐量设置为20，勾选Per User
运行脚本，查看聚合报告如下：

此时可以发现吞吐量控制器2选择Total Executions，吞吐量设置为20参数失效，BeanShell 取样器2线程数等于线程组的线程数

注意事项

● 吞吐量控制器的计算基于其父采样器的执行次数，因此，调整线程组的设置（如线程数、循环次数）会影响吞吐量控制器的实际效果。
● 当使用百分比模式时，确保总百分比不超过100%，否则可能导致预期外的行为。
● 监控测试执行时的实时统计信息，如使用监听器查看结果树或聚合报告，可以帮助验证吞吐量控制器是否按预期工作。

总结

吞吐量控制器是JMeter中一个强大且灵活的工具，通过精确控制请求的执行频次，能够帮助构建更加贴近现实的性能测试场景。正确利用这一特性，可以显著提升测试的准确性和效率，更好地评估系统的性能瓶颈与极限。