4. 响应时间吞吐量错误率怎么分析
响应时间、吞吐量和错误率是性能测试中最核心的三个结果指标。很多同学看 JMeter 聚合报告时，只会看平均响应时间和 TPS，但真正分析性能结果时，必须把这三个指标放在一起看。因为单独一个指标很容易误导：平均响应时间好看，不代表长尾用户体验好；TPS 高，不代表业务成功；错误率低，也不代表系统没有性能问题。
性能测试分析的重点是找到系统在不同压力下的变化趋势：响应时间什么时候开始上升，吞吐量什么时候不再增长，错误率什么时候出现。这些变化通常能帮助判断系统是否接近瓶颈。
一、响应时间怎么看
响应时间表示从发起请求到收到响应所花的时间。
常见统计：
- 平均响应时间；
- 最小响应时间；
- 最大响应时间；
- 中位数；
- 90 线；
- 95 线；
- 99 线。
平均响应时间容易被极端值影响，也可能掩盖长尾问题。性能报告中更推荐关注 95 线和 99 线。
二、为什么要看 95 线
95 线表示 95% 的请求响应时间低于这个值。
例如 95 线是 800ms，说明 95% 的请求在 800ms 内完成。
如果平均响应时间是 200ms，但 99 线是 5s，说明少量请求非常慢，用户体验可能仍然很差。
三、吞吐量怎么看
吞吐量表示单位时间内系统处理的请求或事务数量。
常见指标：
- TPS：每秒事务数；
- QPS：每秒请求数；
- RPS：每秒请求数；
- Throughput：吞吐量。
吞吐量要结合业务看。例如每秒下单数比每秒接口请求数更有业务意义。
四、错误率怎么看
错误率表示失败请求占总请求的比例。
错误包括：
- HTTP 500；
- HTTP 502/503/504；
- 超时；
- 连接失败；
- 业务 code 不正确；
- 断言失败；
- 数据冲突；
- 被限流。
性能测试中，如果没有业务断言，很多失败可能不会被统计出来。
五、三者关系怎么分析
1. 正常阶段
随着并发增加，TPS 上升，响应时间基本稳定，错误率接近 0。
说明系统还有余量。
2. 接近瓶颈
继续增加并发，TPS 增长变慢，响应时间明显上升。
说明系统开始排队或资源紧张。
3. 超过瓶颈
TPS 不再上升甚至下降，响应时间大幅升高，错误率增加。
说明系统已经超出承载能力。
六、典型现象分析
1. 响应时间升高，TPS 也升高
可能是系统承载压力增加但还没到瓶颈。
2. 响应时间升高，TPS 不升
可能已经达到瓶颈，需要看 CPU、数据库、线程池、连接池。
3. TPS 下降，错误率升高
系统可能过载，出现超时、拒绝连接、限流或服务异常。
4. 响应时间波动大
可能有 GC、慢 SQL、缓存穿透、锁竞争、网络抖动或依赖服务不稳定。
七、不能只看平均值
平均值可能掩盖问题。
例如 100 个请求中，99 个请求 100ms，1 个请求 10s，平均值可能看起来还能接受，但那个 10s 请求代表长尾风险。
所以要看分位线和最大值。
八、业务成功率比请求成功率更重要
HTTP 200 不代表业务成功。
例如接口返回：
{"code": 50001, "message": "库存不足"}
HTTP 状态码是 200，但业务是失败的。
所以压测脚本必须加业务断言。
九、分析要结合监控
结果指标只能说明现象，资源指标才能帮助定位。
要结合：
- CPU；
- 内存；
- Load；
- 磁盘 IO；
- 网络 IO；
- 数据库慢 SQL；
- 连接池；
- 线程池；
- GC；
- Redis；
- MQ。
十、面试回答模板
如果面试官问“响应时间、吞吐量、错误率怎么分析”，可以这样回答：
我会把响应时间、吞吐量和错误率放在一起看。响应时间不只看平均值，还要看 95 线、99 线和最大值，避免长尾问题被掩盖；吞吐量关注 TPS 或业务事务数，看随着并发增加是否持续增长；错误率要包含 HTTP 错误、超时和业务断言失败。正常情况下，并发增加时 TPS 上升、响应时间稳定、错误率接近 0；接近瓶颈时 TPS 增长变慢、响应时间开始升高；超过瓶颈后 TPS 不升反降，错误率上升。出现问题后，再结合 CPU、内存、数据库、线程池、连接池、GC 和日志定位瓶颈。
十一、练习清单
- 看平均响应时间；
- 看 95 线；
- 看 99 线；
- 看 TPS 趋势；
- 看错误率；
- 区分 HTTP 成功和业务成功；
- 分析 TPS 拐点；
- 分析响应时间波动；
- 结合 CPU 监控；
- 准备指标分析回答。
性能结果分析不是看单个数字，而是看趋势、关系和瓶颈信号。
配套刷题：
