单台服务器测核心接口极限qps需采用“可控加压+多维观察”：从50并发阶梯式加压，同步监控qps增长、rt变化及cpu/内存等资源，极限值出现在qps停滞、rt骤升、cpu>90%三者交汇处。
单台服务器上测核心接口的极限 QPS，不是一上来就猛加并发，而是用“可控加压 + 多维观察”的方式，把系统推到临界点再收住。关键不在于跑出多高数字，而在于清楚知道这个数字是怎么来的、卡在哪、为什么卡。
明确测试目标和准备基准环境
先锁定你要测的那个核心接口（比如 /api/order/create），确保它不依赖外部强耦合服务（如第三方支付回调），必要时做挡板。服务器环境要干净：关闭无关进程、清空缓存（或固定缓存状态）、确认 JVM 参数/数据库连接池等已按生产相似配置调优。记录初始 CPU、内存、磁盘 I/O、网络收发包等基线值。
用阶梯式加压逼近瓶颈
在 JMeter 中设置线程组，采用“阶梯 ramp-up”而非一次性拉满：比如从 50 并发开始，每 2 分钟增加 50，并持续运行 3 分钟采集稳定数据。每次加压后重点看三项是否同步变化：
- QPS 是否线性增长（Throughput = 样本总数 ÷ 总秒数）
- 平均响应时间是否缓慢上升（
- 错误率是否突增（>0.5% 就要查日志，不是只看 5xx，也要关注超时、熔断、连接拒绝）
识别拐点并确认极限值
极限 QPS 出现在“QPS 停滞 + RT 骤升 + 资源打满”三者交汇处。常见拐点信号：
- CPU 持续 >90%，但 QPS 不再提升 → 计算瓶颈
- CPU
- QPS 达到某值后开始波动下降，同时 Full GC 频繁或 OOM 日志出现 → 内存或 GC 瓶颈
找到拐点后，回退一级压力（比如拐点是 800 QPS，则在 750 QPS 下稳跑 10 分钟），确认该值可持续、无错误、资源可控——这个 750 就是你这台机器上该接口的**实测安全极限 QPS**。
验证结果与反推容量逻辑
得到极限值后，别急着写报告。用 Little’s Law 反向验算：并发数 ≈ 极限 QPS × 平均响应时间（单位秒）。如果算出来并发数远大于你设置的线程数，说明 JMeter 客户端或网络成了瓶颈，要换更高配施压机或改用分布式压测。另外，把该 QPS 值代入容量公式：单机承载量 = 极限 QPS × 冗余系数（通常取 0.7–0.8），得出日常可分配容量，这才是上线部署的真实依据。
