k6底层短时间调度大量API调用机制及RPS上限问题咨询

1. k6 底层请求调度逻辑 #

k6 没有主动根据被测系统（SUT）响应时间对请求做排队限流的设计，也不会无限制以最大速率发请求，它的调度行为由选择的执行器模型决定：

• 你当前使用的 per-vu-iterations 属于封闭模型执行器：每个 VU 是单线程同步执行逻辑，必须等当前迭代的所有操作（包括你配置的 http.batch 中60个请求全部响应完成），才会启动下一次迭代。如果 SUT 响应变慢，VU 等待响应的时间变长，单位时间内可完成的迭代数会自然下降，最终呈现出 RPS 被限制的背压效果，这是调度模型的自然特性，不是 k6 主动触发的限流机制。

2. 测试 RPS 卡在 2000 左右的核心原因 #

从你的测试数据可以明确，瓶颈来自被测系统的处理能力上限，而非 k6 本身的限制：

• 当 VU 从10升到40时，RPS 基本随 VU 数量线性增长，SUT 平均响应时间仅小幅上升，说明此时 SUT 尚未到瓶颈。
• 当 VU 超过40后，RPS 涨幅明显收窄，同时 SUT 平均响应时间大幅上升：VU 从40升到80时，响应时间从134ms涨到238ms；VU 从80升到160时，响应时间直接翻倍到479ms。响应时间的增长完全抵消了 VU 翻倍带来的 RPS 增长，最终 RPS 稳定在 2000~2200 区间。
  你没有观测到报错的原因是 SUT 并未完全过载，只是进入了请求排队处理的状态：所有请求都会被 SUT 放到等待队列中依次处理，只是等待时间变长，所以仅出现响应时间上升，没有触发超时或错误返回。

3. 关于 k6 30万 RPS 性能上限的说明 #

官方提到的最高30万 RPS 是 k6 本身的性能上限，需要满足两个前提：

• 使用开放模型执行器（比如 constant-arrival-rate）：这类执行器不受 SUT 响应时间影响，会按照配置的固定速率发请求，不会因为响应变慢就降低发送速率。
• 有足够的负载机资源支撑。
  你当前使用的封闭模型执行器天然会被 SUT 响应时间限制 RPS 上限，因此完全无法触达 k6 本身的性能上限。
  如果你想进一步验证，可以将执行器替换为 constant-arrival-rate，直接配置高于2000的固定 RPS 压测，此时要么 RPS 成功突破2000（说明之前的限制是封闭模型特性导致），要么会观测到 SUT 响应时间继续升高，甚至出现超时错误（进一步确认 SUT 处理瓶颈）。

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