压力测试的核心指标
做压力测试，你总得知道自己要测什么。我个人习惯先明确目标——不是随便跑个压测脚本就完事了。你得盯住四个关键指标：QPS、TPS、响应时间、错误率。这哥儿四个直接把系统的性能底色给画出来了。
好多人分不清QPS和TPS，我刚开始也犯过迷糊。后来在一个高并发消息推送的项目里被坑过一次——压测报告上QPS很漂亮，但是用户说消息收不到。为什么？因为我把请求量和业务处理量搞混了。来，咱一个个掰扯清楚。
QPS vs TPS：到底差在哪？
先上定义，这张表你收藏一下，面试也常考。
| 指标 | 全称 | 核心含义 | 典型场景 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒查询次数 | 读密集型接口、搜索引擎、信息查询 |
| TPS | Transactions Per Second | 每秒事务数 | 写操作、支付下单、数据库事务提交 |
QPS就是"来了多少请求"，不管你后端干了什么。TPS则是真正完成了多少笔业务操作。举个例子：你点一下"立即购买"，前端可能发3个请求（查库存、生成订单、清购物车）。这时候QPS是3，但TPS只有1。为什么？因为这3个请求合起来才算一笔交易。
我之前做Secret接口设计时，碰到过一个坑：压测客户端只按QPS加压力，结果接口扛住了每秒5000请求，但实际订单落库的TPS只有800。后来一查，其中一个请求每次都做了重复的库存预扣——接口被重复调用了，实际业务完成量却没跟上。所以我的建议是：压测一定要同时上报QPS和TPS，缺一个都不完整。
响应时间：别被平均值骗了
响应时间这事，水很深。很多人只看平均响应时间，觉得"平均50ms，很稳"。嗯，这往往是在给自己挖坑。你想想看，平均响应时间50ms，可能背后藏着一堆1秒以上的慢请求。平均值的最大问题就是会被"好数据"拉低。
我个人习惯用以下统计值：
- P50（中位数）：一半请求比这个快，一半比这个慢。看它基本能代表整体表现。
- P90：90%的请求都低于这个值。如果P90超过200ms，用户就已经能感知到卡顿了。
- P99：1%的慢请求。重点关注P99，往往它才是影响体验的罪魁祸首。
- 最大响应时间：压测过程中最慢的那个请求。但别用它当考核指标，因为它可能是网络抖动或GC停顿导致的孤例。
那P99该怎么定标准？看业务场景：
| 业务类型 | 建议P99 | 说明 |
|---|---|---|
| 接口查询 / 静态资源 | < 200ms | 用户无感知 |
| 业务逻辑接口（如订单） | < 500ms | 可接受轻微等待 |
| 文件上传 / 复杂计算 | < 3s | 配合加载动画 |
| 秒杀 / 高一致性事务 | < 1s | 超时重试要考虑幂等 |
我曾经在某个支付接口上吃过亏。压测报告显示P50只有30ms，大家都觉得完美。结果上线后用户投诉"付款没反应"。查日志发现P99高达2.3秒——因为数据库连接池在高峰期被占满，大量请求在排队。所以听我一句：压测报告里P50、P90、P99必须一起写，缺一个你都不知道问题在哪。
错误率：容忍度是0吗？
理想情况下错误率当然是0%，但实际压测中不能这么死板。得区分错误的类型：
- 业务错误（参数校验失败、库存不足）——这些是正常的，不计入系统吞吐指标。
- 系统错误（500、超时、连接拒绝）——这些才属于性能故障。
我要重点强调的是：错误率是压测的"红灯"。一旦系统错误率超过1%，基本说明系统已经逼近瓶颈了。我自己一般按这个标准：
| 压测阶段 | 错误率上限 | 动作 |
|---|---|---|
| 基准测试（低并发） | 0% | 不允许任何系统错误，否则检查代码 |
| 负载测试（期望压力） | < 0.1% | 记录错误类型，分析原因 |
| 压力测试（高于预期） | < 1% | 如果超过，降低压力或扩容 |
| 极限测试（破坏性） | 可暂时容忍5% | 找到系统崩溃点，记录后恢复 |
注意：错误率必须按时间段统计，不要只算整个压测周期的平均值。我曾经见过一个场景：前9分钟无错误，最后1分钟错误率飙到20%，但全程平均下来只有2%。这样看平均值完全掩盖了问题根源。
四个指标的关系：一张图说清
这四个指标不是孤立的。他们互相影响，共同决定了"系统到底行不行"。下面这张图把核心逻辑串起来了：
压测实战口诀：QPS要看总量，TPS要看有效性，响应时间要看P99，错误率看突发段。这四个值你盯住了，系统的底裤就掀开了。
如何设定这几个指标的压测目标？
目标不能拍脑袋。我一般按下面几步来定：
- 收集历史数据：线上平峰期的QPS、RT（响应时间）平均值和峰值。没有历史数据就估算业务量。
- 确定峰值系数：比如双11大促时可能是平时的10倍。用峰值系数算出挑战目标。
- 设定指标基线：例如QPS目标=5000，P99小于200ms，错误率低于0.1%。
- 拆分微目标：每个接口单独定目标，不能拿全系统平均值混过去。
举个例子：我之前给一个秘密接口（内部鉴权服务）定目标，业务预期每天2亿次调用。算一下：2亿 / 86400秒 ≈ 2315 QPS。我按2.5倍峰值系数，目标设为6000 QPS。然后P99要求<100ms（因为它是上游所有请求的必经之路），错误率0%。压测过程中一旦P99超过120ms，我就开始警觉——说明系统接近瓶颈了。
小技巧：第一次压测时把QPS从低到高逐步递增（比如每步加500），同时记录P99和错误率的变化拐点。那个拐点就是系统的"舒适区上限"。我习惯把这个拐点作为生产环境中限流阈值。
避坑指南
这些坑我踩过不止一次，写出来你可别再跳了：
- 不要只用单机压测推集群：单机压得再好看，一上集群因为网络带宽、分布式锁、数据库连接池争抢，指标可能直接崩。集群压测必须单独做。
- 注意压测工具本身的瓶颈：我曾经用一台笔记本压千兆接口，结果CPU先跑满了——工具本身成了瓶颈。至少用和压测目标相同的机器资源去压。
- 响应时间要分网络延时和业务耗时：我的做法是在接口入口和出口分别打日志，先确认网络开销。如果内网延时都超过5ms，那就别怪后端代码。
- 错误率统计要排除"业务拒绝"：比如库存不足返回的是200+业务码，不是HTTP 500。错误率只应该统计系统层面真正的异常。
嗯，压测指标这块就这些核心内容。你把这四个指标理解了、目标定清楚了，后面做方案设计就能有的放矢。