K6请求量超出预期4倍求助（含Ramping/Constant Arrival Rate场景）

问题原因 #

1. 重定向触发额外请求：k6默认会自动跟随HTTP 3xx重定向，每一次跳转都会发起新的请求。比如你的目标网站https://mywebsite.com如果返回301/302跳转，k6会自动请求跳转后的地址，每个迭代的请求数就会大于1，最终总请求数=迭代速率×每个迭代的请求数，这就导致10次/秒的迭代产生了40次/秒的请求。
2. 混淆迭代速率与请求速率：ramping-arrival-rate和constant-arrival-rate执行器控制的是每秒启动的VU迭代数，而非每秒发送的请求数。如果每个迭代内包含多个请求（包括自动重定向的请求），实际请求数会远超设置的速率。

解决方案 #

1. 排查并处理重定向 #

先验证是否是重定向导致的问题，在脚本中禁用自动重定向，查看原始响应：

export default function () {
    // 禁用自动重定向，查看原始响应状态码和跳转地址
    const res = http.get(`https://mywebsite.com`, { redirects: 0 });
    console.log(`Response status: ${res.status}, Location: ${res.headers.Location}`);
}

根据结果处理：

• 若存在重定向，直接请求最终跳转后的URL，避免额外请求：

  // 替换为实际跳转后的目标URL
  const res = http.get(`https://final-mywebsite.com`);
  

• 若需要模拟真实用户跟随重定向，且已知每个迭代会产生N个请求，将迭代速率设置为10/N（比如每个迭代产生4个请求，就把目标速率设为2.5），以此达到总请求数10 RPS的目标。

2. 确认迭代与请求的对应关系 #

在脚本中添加日志，统计每个迭代的实际请求数，明确问题根源：

export default function () {
    const res = http.get(`https://mywebsite.com`);
    // 打印当前迭代的总请求数（包含重定向请求）
    console.log(`Iteration ${__ITER}: Total requests sent = ${res.requests.length}`);
}

3. 确保阶段配置生效 #

• 检查k6版本，使用最新稳定版避免旧版本的执行器bug；
• 确认maxVUs设置足够（你的配置中maxVUs=50，完全满足10 RPS的需求，无需调整）；
• 运行测试时添加--verbose参数，查看k6日志输出，确认阶段切换是否按预期执行。

4. 精准控制请求速率（可选） #

如果需要严格控制每秒发送的请求数而非迭代数，可基于每个迭代的请求数反向计算迭代速率，或结合per-vu-iterations与sleep实现更精细的控制。

内容的提问来源于stack exchange，提问作者Александр Костюк