Gatling负载测试RPS超出预期问题排查求助

可能的原因及排查步骤 #

1. 请求重试导致RPS虚高 #

如果你的HTTP配置中开启了请求重试（比如http.retry(...)），当请求失败时Gatling会自动重试，这会让实际发送的请求数（即RPS）超过用户注入速率。

• 排查：检查HTTP协议配置，确认是否存在重试逻辑，若不需要则移除。
• 示例：若有类似以下代码，注释或删除重试配置：

  val httpProtocol = http
    .baseUrl("https://your-api.com")
    .retry(2) // 该配置会增加请求数，导致RPS虚高
  

2. 场景中存在隐式循环或重复执行请求 #

虽然你提到每个场景仅包含单个请求，但可能存在代码疏漏（比如误加了forever循环、repeat块），导致单个用户重复发送请求，推高RPS。

• 排查：检查场景定义代码，确保没有循环逻辑。正确的单请求场景应该是：

  val scenario1 = scenario("Scenario 1")
    .exec(http("Request 1")
      .get("/endpoint1"))
  

3. 用户注入速率参数配置错误 #

如果startRate未设为0而是较高值，ramp阶段的初始RPS就会高于预期。比如startRate=2000、maxRate=2000时，ramp阶段会直接以2000的速率注入用户，若后续代码有叠加逻辑，就可能出现RPS超标的情况。

• 排查：确认startRate的取值，若需要从0开始加压，将startRate设为0。

4. maxDuration干扰andThen的顺序执行逻辑 #

你设置的maxDuration(3 * (rampupSeconds + plateauSeconds))看似合理，但如果某个场景的实际执行时间超过rampupSeconds + plateauSeconds（比如请求响应极慢），maxDuration会强制终止测试，可能导致后续场景提前启动，多个场景叠加运行，从而RPS翻倍甚至更高。

• 排查：移除maxDuration配置，andThen本身会保证场景顺序执行，总时间就是三个场景的时间之和，无需额外设置时长限制。

验证方法 #

1. 简化测试：先单独运行一个场景，观察RPS是否稳定在maxRate（2000）。如果单个场景RPS正常，再逐步添加andThen的后续场景。
2. 查看Gatling报告：重点对比用户注入速率和请求RPS的对应关系，确认是否用户注入速率本身超过2000，或者请求数因重试/循环额外增加。

内容的提问来源于stack exchange，提问作者Ali-Ibrahim