一、性能压测核心痛点：如何找准最大并发数？
在很多项目的性能测试初期，架构师或业务方往往无法给出精准的系统容量指标，只会提出类似“帮我测测这个核心服务最大能抗住多少并发”的模糊需求。
如果直接使用普通线程组一次性打入 1000 并发：
- 系统大概率直接被打死，日志全量报错，无法得知系统到底是在 200、500 还是 800 并发时开始出现衰竭；
- 无法绘制出完整的系统吞吐量上升、饱和与拐点衰退曲线。
科学的性能负载测试方法是：梯度渐进加压（Stepping Load Testing），通过分阶段阶梯式增加虚拟用户，逼近系统的临界性能拐点。
二、阶梯加压线程组（Stepping Thread Group）设计
通过 JMeter 插件管理器（Plugins Manager）安装 Custom Thread Groups 插件，引入 jp@gc - Stepping Thread Group。
1. 梯形加压模型设计思路
假设初步预估系统承载在 0 ~ 100 并发之间，设置两阶段测试策略：
text
并发用户数 (Threads)
▲ ┌────────────┐ (阶段平台期稳定运行)
50│ ┌───────────┘
30│ ┌───────────┘
10│ ┌───────┘ (每步长运行 30s 收集平稳指标)
└─┴───┴───┴────────────────────────────────────► 时间 (t)- 初测（大步长探测区间）：
- 初始启动 10 个线程；
- 保持稳定运行 30 秒；
- 随后每 5 秒增加 10 个线程，梯级递增至 50；
- 观察核心监控指标的突变点。
2. 核心监听器组合：
Active Threads Over Time：活跃虚拟用户阶梯曲线；Transactions per Second (TPS)：每秒事务吞吐走势；Response Times Over Time：响应耗时变化曲线。
三、系统最大并发承载量的三大判定红线
在阶梯加压过程中，当出现以下任意一种现象时，当前并发数即判定为系统承载上限临界点：
- 响应时间突破行业 SLA 红线：核心 API 平均响应时间超过 1.5 秒（对于要求严格的高频微服务通常为 500ms），99 分位数出现陡峭上升。
- TPS 曲线出现拐点衰退：随着并发用户数继续增加，TPS 不仅不再增长，反而出现明显平缓或持续下滑（说明系统 CPU 调度或锁等待已出现严重饱和）。
- 接口错误率（Error Rate）突破阈值：出现连续的连接超时（
Connection Timeout）、HTTP 502/504 网关报错，且错误率超过 0.1%。
二阶段：缩减步长精准收敛
如果初测发现并发在 10 ~ 20 之间 TPS 出现拐点且耗时超过 1.5s，接着进行第二轮精细化测试：
- 以 10 为基准；
- 每隔 15 秒仅增加 1 个并发；
- 精准测出系统是在 14 还是 17 并发时达到真正的物理瓶颈。
四、生产环境无 GUI 执行与报告生成规范
严禁在生产压测机上直接开启 JMeter 图形化界面跑压测！ GUI 模式本身的 Java Swing 渲染会吞噬大量的客户端 CPU 与内存，导致施压机自身成为瓶颈。
采用非 GUI 命令行标准规范：
bash
# -n: 非 GUI 模式
# -t: 测试脚本路径 (.jmx)
# -l: 原始采样结果记录文件 (.jtl)
# -e -o: 测试结束后自动生成 HTML 动态分析报表
jmeter -n -t /opt/stress_test/order_benchmark.jmx \
-l /opt/stress_test/results.jtl \
-e -o /opt/stress_test/html_report生成的 HTML 报表包含完整的 APDEX 满意度评分、TPS 趋势、吞吐分位数（Percentiles）与网络流量统计，为容量规划提供严密的数据支撑。