Constant Throughput Timer无法从预处理器正确获取吞吐量值问题求助

问题场景 #

现有数百万样本的动态RPS日志（测试用例RPS序列为[5,10,5,20]），通过JSR223预处理器设置全局属性传递RPS值：

props.put("throughput", num_of_reqs);

使用Constant Throughput Timer按该动态值控制TPS，但实际结果始终低于5，未达到预期。

核心原因及对应解决方法 #

1. 吞吐量单位不匹配（最可能原因） #

Constant Throughput Timer默认吞吐量单位是每分钟请求数，而非每秒。如果直接传入每秒RPS值（比如5），Timer会将其解析为每分钟5次请求，对应每秒仅约0.08次，远低于预期。

解决方法：
将计算出的每秒RPS值乘以60，转换为每分钟吞吐量后再设置属性：

props.put("throughput", num_of_reqs * 60);

2. 预处理器执行时机错误 #

如果预处理器（如JSR223 PreProcessor）的位置在Constant Throughput Timer之后，Timer无法获取到最新的throughput属性值，会一直使用初始值或默认值。

解决方法：
将预处理器移动到Constant Throughput Timer之前（线程组内最靠前的位置），确保每次迭代前都能更新吞吐量属性。

3. 线程数不足 #

若线程组设置的线程数量不足以支撑目标RPS，即使Timer配置正确，也无法达到预期TPS。例如：目标RPS为20，若平均响应时间为1秒，至少需要20个线程；若响应时间为2秒，则需要40个线程。

解决方法：
根据最大目标RPS和平均响应时间计算所需线程数，公式为：
所需线程数 = 最大RPS × 平均响应时间
在线程组中设置足够的线程数量，同时可配合Ramp-Up Period确保线程平稳启动。

4. Timer作用范围或计算模式配置错误 #

Constant Throughput Timer的“Calculate Throughput based on”选项决定了吞吐量的计算范围，若配置不当会导致实际吞吐量被分摊：

• 若选择“All active threads (shared)”，吞吐量会被所有线程组共享，单线程组的实际TPS会远低于目标值；
• 若Timer仅作用于部分请求而非整个事务，统计的TPS也会不符合预期。

解决方法：

• 单线程组场景下，选择“This thread group”作为计算基准；
• 确保Timer的作用范围覆盖整个事务的所有请求（将Timer放在线程组级别，或包裹所有事务请求）。

5. 属性值未正确传递 #

需确认throughput属性是否被正确设置为预期值。

解决方法：
添加Debug Sampler，勾选“JMeter Properties”，运行测试后查看throughput属性的实际值，验证是否为转换后的每分钟吞吐量（如5对应300，10对应600等）。

内容的提问来源于stack exchange，提问作者Akshara Sneha