Gatling incrementConcurrentUsers测试AWS微服务自动扩缩容配置问题

问题核心根因 #

当前配置失效的核心原因有两点：

1. 负载模型不匹配：incrementConcurrentUsers是并发用户维度的阶梯负载模型，而constantUsersPerSec是每秒新增用户维度的吞吐模型，两个模型统计逻辑完全不同，无法直接通过andThen衔接实现“爬升到最大负载后保持”的效果。
2. andThen机制逻辑问题：andThen会在前一个注入剖面完全终止后才启动下一个剖面，切换瞬间前一段的所有并发用户会被全部释放，后一段从零开始注入新用户，直接导致负载断层掉底，和观测到的异常曲线现象完全吻合。

另外原配置参数没有做对齐：阶梯段最终的最大并发数为20 + 20*120 = 2420，和后续恒定段设置的300用户/秒没有量级对应关系，会进一步放大负载跳变。

可直接复用的正确配置 #

如果测试目标是阶梯爬升验证扩缩容触发逻辑、爬到最大负载后保持恒定并发持续压测（这也是自动扩缩容验证最常用的负载模型，和AWS Target Tracking类扩缩容策略的指标匹配度最高），不需要拆分两个inject块用andThen，直接在同一个注入剖面中组合阶梯和恒定并发步骤即可，配置如下：

scn.inject(
  // 阶梯加压段：从20并发起步，每次提升20并发，共120个阶梯
  incrementConcurrentUsers(20)
    .times(120)
    .eachLevelLasting(150 seconds)
    .separatedByRampsLasting(50 seconds)
    .startingFrom(20),
  // 恒定负载段：对齐阶梯终点的最大并发2420，持续运行30分钟
  constantConcurrentUsers(2420).during(30 minutes)
)

参数说明：最大并发数计算逻辑为「起始并发数 + 单阶梯增量 * 阶梯次数」，和阶梯段最终负载完全对齐，切换过程不会出现负载断层。

AWS环境测试补充注意事项 #

• 提前校验Gatling压测集群的网络带宽、CPU配额、临时端口上限，避免压测端自身成为瓶颈，导致负载曲线失真
• 确认微服务自动扩缩容的指标采集间隔、扩缩容冷却时间和单阶梯150秒的持续时长匹配，保证每个阶梯负载稳定后，扩缩容动作有足够时间完成、新实例能正常注册接管流量
• 恒定负载运行阶段不要调整压测流量，重点观测扩缩容是否会在实例数匹配负载需求后进入稳定状态，无频繁扩缩容抖动

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