constant-arrival-rate执行器请求速率不符及VU相关问题咨询

配置信息 #

{
  executor: 'constant-arrival-rate',
  duration: '1800s',
  rate: 1170,
  timeUnit: '1s',
  preAllocatedVUs: 50,
  maxVUs: 3500
}

核心问题 #

预期每秒产生1170个请求，但实际http_reqs仅为169.239844/s，远低于预期，以下是针对疑问的解答：

疑问1：配置maxVUs=3500和rate=1170，是否意味着每个VU每秒发起1170次请求？ #

完全不是这个逻辑。rate+timeUnit的组合是全局每秒要发起的迭代（请求）总数，而非单个VU的请求量。你配置的是每秒要发起1170次迭代，k6会自动调度足够VU维持该速率，直到触及maxVUs上限。

实际请求量偏低的核心原因：

• 测试数据显示dropped_iterations: 597056 962.853179/s，大量迭代被丢弃；
• 结合WARN日志Insufficient VUs, reached 3500 active VUs and cannot initialize more，以及http_req_duration平均20.21s的指标，单个VU完成一次迭代需约20秒，每秒仅能处理约0.05次请求。要达到1170次/秒的速率，需1170*20≈23400个VU，但你配置的maxVUs仅3500，远不足以支撑目标速率，导致大量迭代被丢弃，实际请求量无法达标。

疑问2：constant-arrival-rate执行器中，VU如何配合恒定请求速率工作？ #

这个执行器的核心是优先保证设定的请求速率，VU是支撑速率的执行资源，工作逻辑如下：

• k6按rate/timeUnit的频率持续生成新的迭代任务；
• 迭代任务优先分配给空闲VU执行；
• 无空闲VU时，k6会启动新VU（直到达到maxVUs上限）；
• 当所有VU忙碌且已达maxVUs时，新迭代任务会被直接丢弃（对应dropped_iterations指标）；
• VU完成当前迭代后，立即接收下一个等待任务，不会空闲。

简言之，VU是执行请求的"载体"，k6根据速率需求动态调配，载体不足时只能放弃部分任务。

疑问3：测试结果中vus_max的最小值为359，是否代表全程仅启用了359个VU？ #

不是。vus_max是测试过程中VU数量最大值的统计区间：

• min=359指测试周期内，不同时间点统计到的vus_max最小值为359（即测试初期VU数量增长阶段的某个峰值）；
• max=3500指测试后期已达到VU上限3500，且后续一直维持该数量（从第11秒的WARN日志可看出已触达上限）。

测试结果关键指标补充解读 #

• dropped_iterations：每秒丢弃近963次迭代，直接证明VU资源不足以支撑目标速率；
• http_req_duration平均20.21s：被测试服务响应极慢，是需要大量VU的根本原因；
• http_reqs: 169.239844/s：实际完成请求量与3500个VU / 单迭代20秒 ≈175次/秒的计算值基本吻合，符合当前资源限制下的结果。

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