在Karate Gatling中模拟指定梯度+并发混合负载的实现是否合理？

需求与当前实现 #

我的需求是搭建时长1小时的负载测试，具体场景如下：

• 5分钟内将用户数从0梯度提升至140
• 维持140并发用户30分钟
• 15分钟内将用户数从140梯度提升至160
• 维持160并发用户10分钟

我编写了如下Scala脚本：

package features.Performance
import com.intuit.karate.gatling.PreDef._
import io.gatling.core.Predef._
import scala.concurrent.duration.DurationInt

class PerfTests extends Simulation {

  before {
    println("Perf tests started")
  }

  val getTest1 = scenario("Performance test for ramp user(0 to 140)").exec(karateFeature("classpath:features/Performance/Perf.feature"))
  val getTest2 = scenario("Performance test for concurrent users 140").exec(karateFeature("classpath:features/Performance/Perf.feature"))
  val getTest3 = scenario("Performance test for ramp user(140 to 160)").exec(karateFeature("classpath:features/Performance/Perf.feature"))
  val getTest4 = scenario("Performance test for concurrent users 160").exec(karateFeature("classpath:features/Performance/Perf.feature"))

  setUp (    
    getTest1.inject(rampUsersPerSec(0) to (140) during( 5 minutes)),
    getTest2.inject(constantConcurrentUsers(140).during(30 minutes)),
    getTest3.inject(rampUsersPerSec(140) to (160) during( 15 minutes)),
    getTest4.inject(constantConcurrentUsers(160).during(10 minutes))
    
  ).assertions(
    global.responseTime.max.lt(10000))

  after {
    println("Perf tests ended")
  }
}

其中Perf.feature包含一个简单的Post请求。请问这种实现方式是否正确，或者有没有更优的方法来模拟该负载？

问题分析与优化方案 #

当前实现的问题 #

你的脚本存在核心逻辑错误：同时启动4个独立场景会导致并发用户数叠加，完全偏离预期的负载曲线。比如前5分钟内，getTest1在提升用户数的同时getTest2维持140并发，实际并发量会远高于140，后续阶段的用户数叠加问题更严重。

优化后的实现 #

使用Gatling的多阶段注入特性，在单个场景中串联所有负载阶段，精准匹配需求：

package features.Performance
import com.intuit.karate.gatling.PreDef._
import io.gatling.core.Predef._
import scala.concurrent.duration.DurationInt

class PerfTests extends Simulation {

  before {
    println("Perf tests started")
  }

  // 复用单个场景，避免重复定义
  val perfScenario = scenario("1-hour Gradient Load Test").exec(karateFeature("classpath:features/Performance/Perf.feature"))

  setUp(
    perfScenario.inject(
      // 阶段1：5分钟内从0梯度提升至140并发用户
      rampConcurrentUsers(0) to 140 during (5 minutes),
      // 阶段2：维持140并发用户30分钟
      constantConcurrentUsers(140) during (30 minutes),
      // 阶段3：15分钟内从140梯度提升至160并发用户
      rampConcurrentUsers(140) to 160 during (15 minutes),
      // 阶段4：维持160并发用户10分钟
      constantConcurrentUsers(160) during (10 minutes)
    )
  ).assertions(
    global.responseTime.max.lt(10000)
  )

  after {
    println("Perf tests ended")
  }
}

关键优化说明 #

• 替换rampUsersPerSec为rampConcurrentUsers：你的需求是控制并发用户数，rampUsersPerSec是控制每秒启动的用户数，逻辑不符。rampConcurrentUsers会精准维持系统中同时活跃的用户数量，完全匹配场景要求。
• 单场景串联多阶段：所有负载阶段绑定到同一个场景，确保阶段按顺序执行，不会出现用户数叠加，严格遵循1小时的负载变化曲线。
• 代码复用与简洁性：只定义一个场景，减少冗余代码，后续维护更高效。

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