阶梯式加压是评估系统最大吞吐量最常用、最有效的负载测试策略，通过分阶段增加并发数并观察TPS、响应时间、错误率等指标变化来定位性能拐点和瓶颈。
阶梯式加压是评估系统最大吞吐量最常用、也最有效的负载测试策略。它的核心不是“一口气压到极限”，而是通过可控、分阶段的并发增长，观察系统在每个负载台阶上的响应时间、错误率、TPS 等指标变化，从而定位性能拐点和瓶颈。
明确加压目标与关键参数
设计前先锁定三个基础目标：
- 起始并发数：通常设为 10–50，避免冷启动抖动干扰基线数据；
- 每阶增量与节奏：例如“每 30 秒增加 50 个用户”，节奏不宜过快（否则像脉冲），也不宜过慢（测试周期拉太长）；
- 稳态观察时长：每个台阶后至少保持 60–180 秒，确保指标收敛，能真实反映该负载下的吞吐能力。
选用合适的线程组并配置阶梯逻辑
推荐使用 jp@gc - Stepping Thread Group（稳定成熟）或 bzm - Concurrency Thread Group（更贴近真实并发控制）：
-
Stepping Thread Group 示例配置：
— This group will start: 0
— First, wait for: 30 秒（采集空载基线）
— Then start: 50（第一阶）
— Next, add: 50 threads every 30 seconds（每 30 秒加 50）
— using ramp-up: 5 秒（新增的 50 个用户在 5 秒内均匀启动，避免瞬时冲击）
— Then hold load for: 120 秒（每阶稳压 2 分钟）
— Finally, stop: 可不设，或最后统一降压 - Concurrency Thread Group 更适合吞吐导向：直接设定 Target Concurrency（如 50→100→150→200），Ramp Up Time 控制总爬坡时长（如 2 分钟内从 0 到 200），Hold Target Rate Time 设为 120 秒以上，便于观察 TPS 是否随并发线性增长。
配套监控与关键指标判据
光加压不够，必须同步采集并交叉分析以下指标：
- TPS（Transactions per Second）：用 jp@gc - Transactions per Second 监听器查看。当并发持续上升但 TPS 增速明显放缓甚至持平，即进入“吞吐平台期”，此时的 TPS 接近系统理论最大吞吐量；
- 平均响应时间 & 90%线：配合 Response Times Over Time。若响应时间随并发呈指数上升（如从 200ms → 1200ms），说明服务已开始排队或资源争抢；
- 错误率突增点：聚合报告中错误率 > 1% 且持续上升，往往是吞吐量不可持续的信号；
- 活跃线程数曲线：用 Active Threads Over Time 验证实际并发是否按预期增长，排除脚本或中间件限流干扰。
识别最大吞吐量的实操判断法
不是看“最高并发数”，而是看“最高可持续 TPS”：
- 当某阶并发下，TPS 达到峰值（比如 850 TPS），下一阶并发提升后 TPS 不升反降（如 820 TPS），且错误率跳升、响应时间翻倍 → 此前一阶的 TPS 就是当前环境下的最大吞吐量；
- 若 TPS 持续线性增长，但 CPU/内存已达 85%+，数据库连接池打满 → 吞吐瓶颈不在应用层，需结合资源监控反推理论上限；
- 建议在达到疑似拐点后，单独补做一轮“稳态压测”：用该并发值持续运行 10 分钟，验证 TPS 和错误率是否稳定——稳定才可认定为可靠的最大吞吐量。
