Jmeter Throughput Shaping Timer实际吞吐量与预期不符问题

以下是导致该问题的常见原因及对应的排查方向：

• Throughput Shaping Timer（TST）配置错误

  • 核对目标吞吐量的单位与数值：确认是否误将"Requests per Second"设为"Requests per Minute"，或者目标值输入错误（比如填了230而非120）。
  • 检查时间阶段设置：如果测试前10分钟的吞吐量目标被错误配置为阶梯式增长到230，会直接导致实际吞吐量超标。
  • 验证作用范围：确保TST的"Apply to"选项覆盖了所有需要控制的采样器，没有遗漏或错误关联其他组件。

• Concurrency Thread Group（CTG）与TST未正确联动

  • 检查CTG的线程数计算方式：必须在"Calculate Thread Count Using"中选择对应的TST实例，否则CTG会按自身逻辑（如固定线程数）运行，无法根据TST的吞吐量目标动态调整线程数。按响应时间1000-1800ms计算，120 RPS所需的理论线程数范围是120-216，如果CTG的线程数远高于这个范围，必然导致吞吐量超出预期。
  • 确认CTG的线程数限制：如果CTG设置了过高的最大线程数，且未被TST有效约束，多余的线程会持续发起请求，推高总吞吐量。

• Dummy Sampler的响应时间配置未生效

  • 检查延迟设置：确认Dummy Sampler已勾选"Delay"选项，并正确设置了1000-1800ms的响应时间范围。如果未启用延迟或设置值错误，实际响应时间会远低于预期，线程能快速循环发起请求，导致吞吐量飙升。
  • 验证实际响应时间：通过结果树或聚合报告查看每个Dummy Sampler的实际响应时间，确认是否符合1000-1800ms的预期。如果实际响应时间远低于该范围，说明延迟配置未生效。

• 吞吐量计算模式错误

  • 检查TST的"Throughput Calculation"选项：如果选择了"Per Thread"而非"Total"，TST会按每个线程的吞吐量目标计算总吞吐量，线程数乘以单线程目标会远超120 RPS。务必设置为"Total"以控制全局总吞吐量。

• 存在未被控制的额外请求

  • 检查测试计划：确认是否有其他采样器、循环控制器或逻辑分支在发起未被TST纳入控制的请求，这些额外请求会叠加到总吞吐量中，导致数值超标。

内容的提问来源于stack exchange，提问作者Kevin Lee