Gatling 3.11：如何用Closed模型实现0.16-1 RPS的负载测试？

Closed模型的核心是基于并发用户数控制负载，每个用户会循环执行测试场景，实际RPS由「并发用户数 × 单用户的请求周期（请求执行时长+等待/思考时长）」决定。由于它仅支持整数并发用户数，没法直接设置0.16这类小数RPS，我们可以通过控制单用户的请求节奏，配合并发数的逐步提升来实现目标负载范围。

具体实现步骤 #

1. 计算初始RPS对应的请求间隔
   0.16 RPS等价于每6.25秒发起一次请求（计算公式：1 / 0.16 = 6.25）。我们可以用1个并发用户，通过固定请求间隔来达到这个初始RPS。

2. 结合并发数递增与请求间隔调整实现RPS提升
   如果目标最终是1 RPS，有两种可行思路：

• 思路一：固定并发数，逐步缩短请求间隔
  保持1个并发用户，逐步把请求间隔从6.25秒降到1秒（1 / 1 = 1秒），就能让RPS从0.16提升到1。
• 思路二：逐步增加并发数，固定请求间隔
  保持单用户每6.25秒发起一次请求，逐步增加并发用户数：1个用户对应0.16 RPS，6个用户对应0.96 RPS（接近1）；如果需要精确到1 RPS，可以微调请求间隔到6秒，6个用户就能达到1 RPS（6 / 6 = 1）。

代码示例（以Gatling为例） #

思路一：固定并发数，调整请求间隔

scenario("Low to High RPS Closed Test")
  .exec(http("Test Request").get("/your-target-api"))
  // 分阶段调整请求间隔，配合固定的1个并发用户
  .pace(6.25 seconds) during (10 minutes) // 初始阶段：0.16 RPS
  .pace(3 seconds) during (10 minutes)    // 中间阶段：~0.33 RPS
  .pace(1 second) during (10 minutes)     // 最终阶段：1 RPS
.injectClosed(
  constantConcurrentUsers(1) during (30 minutes) // 全程保持1个并发用户
)

思路二：递增并发数，固定请求间隔

scenario("Low to High RPS Closed Test")
  .exec(http("Test Request").get("/your-target-api"))
  .pace(6 seconds) // 固定单用户每6秒发起一次请求
.injectClosed(
  constantConcurrentUsers(1) during (10 minutes), // 初始：1/6 ≈0.17 RPS，接近目标0.16
  incrementConcurrentUsers(1)
    .times(5) // 每次加1个用户，共加5次，最终到6个用户
    .eachLevelLasting(10 minutes), // 每个并发级别持续10分钟
  constantConcurrentUsers(6) during (10 minutes) // 最终：6/6=1 RPS
)

注意事项 #

• 如果请求本身的执行时长不可忽略，需要把它算进请求周期里，调整等待时间来保证实际RPS符合预期。比如请求执行平均耗时0.25秒，那初始的等待时间就应该设为6秒（6.25 - 0.25），才能保证总周期是6.25秒。
• Closed模型更适合模拟真实用户的持续操作场景，如果只是单纯追求精准的RPS控制，Open模型会更直接；但如果业务场景必须用Closed模型，上述方法可以满足需求。

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