JMeter如何结合Stepping/Ultimate线程组与While控制器实现pacing

LoadRunner的Pacing核心规则为：控制相邻两次业务迭代的起始时间间隔为固定值，若单次迭代业务总耗时小于设定Pacing值，自动补足等待差值；若迭代耗时超过Pacing值，直接进入下一次迭代，无额外等待。

现有常见配置误区 #

• 单独使用Flow Control Action配置固定等待：最终迭代间隔=业务耗时+固定等待时长，和LR Pacing逻辑完全不符
• BeanShell Timer直接写入固定sleep值：无法动态计算待补等待时长，且BeanShell解释执行的特性会在高并发下带来不必要的性能损耗
• While控制器循环条件设为true：容易出现死循环，且会和线程组的加压、持续时长配置冲突
• 多层循环嵌套：在线程组、While控制器同时配置循环次数，会导致Pacing时间计算错位

正确配置步骤 #

1. 核心Pacing逻辑实现（完全对齐LR规则） #

优先使用JSR223组件+Groovy实现，性能损耗可忽略，时间精度高，不需要额外依赖BeanShell、Flow Control Action组件：

• 在While控制器内部、所有业务逻辑的最前端，添加JSR223 Sampler，勾选Cache compiled script if available，写入如下代码记录迭代起始时间：

// 记录当前迭代启动时间戳（毫秒）
vars.putObject("iterationStart", System.currentTimeMillis())
// 配置目标Pacing时长，单位毫秒，例：3000代表3秒间隔
vars.putObject("targetPacing", 3000L)

• 将所有业务请求、参数化、关联、断言逻辑按执行顺序放在上述JSR223 Sampler之后
• 在While控制器内部、所有业务逻辑的最末端，添加第二个JSR223 Sampler，同样勾选缓存编译选项，写入动态等待逻辑代码：

long start = vars.getObject("iterationStart") != null ? (long) vars.getObject("iterationStart") : System.currentTimeMillis()
long pacing = (long) vars.getObject("targetPacing")
long cost = System.currentTimeMillis() - start
long wait = pacing - cost
// 迭代耗时小于Pacing时补足等待，超时则直接进入下一轮
if (wait > 0) {
    sleep(wait)
}
// 调试阶段可打开日志确认耗时，正式压测注释即可
// log.info("迭代耗时：{}ms，Pacing等待：{}ms", cost, wait > 0 ? wait : 0)

注意：不要在脚本中额外添加作用域覆盖全请求的Timer组件，避免重复等待导致间隔不准

2. While控制器配置 #

不要直接将循环条件设为true，根据压测模式选择对应条件即可：

• 按固定迭代次数压测时，循环条件填：

  ${__jexl3(vars.getIteration() <= ${__P(totalIterations,1000)},)}
  

  其中totalIterations为可配置的单线程总迭代次数
• 按持续时长压测时，循环条件填：

  ${__jexl3(${__jm__Stepping Thread Group__elapsedTime} < ${__P(testDuration,300000)},)}
  

  若使用Ultimate线程组，将条件中Stepping Thread Group替换为Ultimate Thread Group即可，testDuration为压测总持续时长（单位毫秒）

3. 线程组适配配置 #

Stepping阶梯线程组适配

• 将线程组配置项中的Iterations值设为1，所有循环逻辑完全交给内部While控制器控制，避免多层循环冲突
• 按原有需求配置线程爬升阶梯、峰值持续时长、降载规则即可，Pacing逻辑和加压逻辑完全解耦，互不影响

Ultimate线程组适配

• 所有线程调度行的Iterations字段统一设为1
• 按需求配置各批次线程的启动延迟、爬升时长、峰值持续时长、关闭时长即可，无需调整Pacing相关代码

效果验证 #

• 调试阶段可通过结果树查看相邻两次迭代首个请求的发起时间差，稳定等于设定的Pacing值（误差10ms内为正常范围）即配置正确
• 若出现迭代间隔大于Pacing值的情况，优先排查业务请求本身耗时是否已超过Pacing设定，该表现和LR Pacing逻辑完全一致
• 正式压测时禁用所有调试类监听器，避免额外性能消耗影响压测结果准确性

内容的提问来源于stack exchange，提问作者NOMADIC RiSHI