压测目标设定：性能基线、目标吞吐量、响应时间SLA、资源利用率上限、压测通过标准
做压测这么多年，我见过太多团队一上来就猛怼流量，结果测完一脸懵——这结果到底是好是坏？没人说得清。说白了，就是缺了目标。
没有目标的压测，就像没有靶子的射击。你打再多的子弹，也不知道自己准不准。今天我们就聊聊，怎么把压测目标定清楚。
性能基线：你的起点在哪
性能基线，就是系统当前的能力水平。我习惯叫它「体检报告」。没有基线，你根本不知道这次压测是进步了还是退步了。
举个例子。你接手一个老系统，线上TPS大概500，平均响应时间200ms。那这就是你的基线。下次压测，如果TPS到了600，响应时间降到150ms，说明优化有效。反之，如果TPS掉到400，那就要排查问题了。
基线通常包含哪些指标？
- 平均TPS / QPS
- 平均响应时间（Avg RT）
- P95 / P99 响应时间
- 错误率
- CPU、内存、IO 等资源使用情况
我在项目中遇到过一件事。有个团队说系统性能提升了30%，我问基线是多少？他们答不上来。后来一查，原来基线数据是半年前的，中间系统架构都重构过了。你想想看，拿半年前的数据当基线，这对比还有什么意义？
我的建议：基线要定期更新。每次大版本发布后，重新跑一轮基线压测。我一般每两周更新一次，遇到重大变更随时更新。
目标吞吐量：你到底要扛多少
目标吞吐量，就是系统需要达到的处理能力。这个数字不是拍脑袋定的，得从业务需求来。
怎么算？我一般这么干：
- 看峰值流量——过去一年线上最高的QPS是多少？
- 加冗余——峰值基础上再加30%-50%的余量。为什么？因为流量会涨，系统要留点余粮。
- 考虑未来——如果业务预期增长，目标吞吐量也要跟着调。
举个例子。某电商系统，去年双十一峰值QPS是10000。那目标吞吐量可以定在15000。为什么？因为今年用户量涨了，活动力度也大了，得留够余量。
注意：目标吞吐量不是越高越好。定得太高，硬件成本飙升；定得太低，线上扛不住。我曾经见过一个团队，目标定到20000 QPS，结果硬件预算翻了3倍，老板直接拍桌子。后来我们重新评估，发现实际峰值只有8000，目标定到12000就足够了。
响应时间SLA：用户能等多久
响应时间SLA，就是你对用户的承诺。比如「99%的请求在200ms内返回」。这个承诺不是随便写的，得看业务场景。
我习惯把响应时间分成几个等级：
| 业务类型 | 建议SLA | 说明 |
|---|---|---|
| 核心交易（下单、支付） | P99 < 200ms | 用户耐心最低，慢了就流失 |
| 列表查询（商品、订单） | P99 < 500ms | 可以接受稍慢，但不能卡死 |
| 后台报表 | P99 < 3s | 内部使用，容忍度较高 |
| 批量任务 | P99 < 30s | 异步处理，用户不感知 |
为什么会这样？因为用户对不同类型的请求，耐心是不一样的。你想想看，点个支付按钮等3秒，你肯定骂娘。但导出个报表等30秒，你可能觉得正常。
我曾经踩过一个坑。有个项目把SLA统一设为P99 < 200ms，结果后台报表接口天天报警。后来才发现，报表查询要扫描几百万条数据，200ms根本不可能。最后我们把报表的SLA放宽到3秒，世界清净了。
我的习惯：SLA要分接口、分场景定。核心接口严格，非核心接口宽松。别一刀切。
资源利用率上限：别把机器跑死
资源利用率上限，就是给系统划一条红线。超过这条线，系统可能出问题。常见的资源包括CPU、内存、磁盘IO、网络带宽。
我一般这么定：
- CPU：不超过70%。为什么不是100%？因为CPU到100%时，系统已经严重卡顿了。留30%给突发流量和系统进程。
- 内存：不超过80%。内存用满会导致OOM，进程被kill。留20%给缓存和临时对象。
- 磁盘IO：不超过60%。磁盘IO是慢设备，超过60%后延迟会急剧上升。
- 网络带宽：不超过50%。网络拥堵会导致丢包和重传，影响性能。
一个真实案例：有次压测，CPU跑到85%，TPS还在涨。团队觉得没问题，结果线上流量一来，CPU直接飙到100%，系统雪崩。后来我们复盘，发现85%已经是临界点了。从那以后，CPU上限我坚决定在70%。
嗯，这里要注意。资源利用率上限不是死的。如果你的机器配置高、业务模型简单，可以适当放宽。但保守一点总没错。
压测通过标准：怎么才算过
压测通过标准，就是所有目标都达标了，才能说「这次压测通过了」。我习惯用一张检查清单：
| 检查项 | 标准 | 说明 |
|---|---|---|
| 目标吞吐量 | 达到或超过设定值 | 比如目标15000 QPS，实际要跑到15000+ |
| 响应时间SLA | P99 在阈值内 | 比如P99 < 200ms |
| 错误率 | < 0.1% | 允许少量错误，但不能超过千分之一 |
| 资源利用率 | 所有指标在上限内 | CPU < 70%，内存 < 80% 等 |
| 稳定性 | 持续运行30分钟无异常 | 短时间达标不算，要能稳住 |
我一般还会加一条：压测结束后，系统能自动恢复。什么意思？就是压测停了，CPU、内存能降回正常水平。如果降不下来，说明有内存泄漏或资源未释放的问题。
避坑指南：我曾经遇到一个项目，压测时所有指标都达标，但压测一停，CPU死活降不下来。后来查了三天，发现是一个线程池没做回收。所以通过标准里，一定要加上「恢复性检查」。
一张图看懂压测目标设定
下面这张图，把整个目标设定的逻辑串起来了。从业务需求出发，一步步推导出压测通过标准。
你看，从业务需求出发，拆解出四个核心目标。每个目标都有明确的量化标准。最后汇总成压测通过标准。这样整个流程就清晰了。
小结
压测目标设定，说白了就是回答四个问题：
- 你现在在哪？（基线）
- 你要去哪？（目标吞吐量）
- 路上能堵多久？（响应时间SLA）
- 车不能开散架了（资源利用率上限）
这四个问题都答清楚了，压测通过标准自然就出来了。我每次做压测，都会先把这些目标写下来，贴在工位上。测完了，一条条对照检查。过了就是过了，没过就找原因。简单、直接、有效。
记住，没有目标的压测，就是瞎忙活。