6. 性能瓶颈定位思路
性能瓶颈定位是性能测试面试中最能拉开差距的问题。会跑 JMeter 的人很多，但能根据响应时间、TPS、错误率、CPU、内存、数据库、线程池、连接池、GC、日志等信息定位瓶颈的人不多。面试官问瓶颈定位，真正想听的是你的分析路径，而不是随便说“可能是数据库问题”。
性能瓶颈定位要遵循一个原则：先看现象，再看资源，再看链路，最后验证猜想。不要一上来就下结论。
一、先描述现象
性能问题常见现象：
- 响应时间升高；
- TPS 上不去；
- TPS 下降；
- 错误率上升；
- 超时增多；
- CPU 打满；
- 内存持续上涨；
- 数据库慢 SQL；
- 连接池耗尽；
- MQ 积压。
不同现象对应不同排查方向。
二、看压测结果趋势
先看三条曲线：
- 响应时间；
- TPS；
- 错误率。
如果并发增加后，TPS 不再增长、响应时间继续升高，说明系统达到瓶颈。
如果错误率上升，要看是 HTTP 错误、超时、业务错误还是断言失败。
三、看应用服务器资源
应用服务器关注：
- CPU 使用率；
- Load；
- 内存；
- GC；
- 线程数；
- 线程池队列；
- 连接池；
- 日志错误。
CPU 高可能是计算密集、锁竞争、频繁 GC 或代码循环问题。
CPU 不高但响应慢，可能是等待数据库、网络、外部服务或锁。
四、看数据库
数据库是常见瓶颈。
关注：
- 慢 SQL；
- SQL 执行计划；
- 索引是否命中；
- 连接数；
- 锁等待；
- 行锁表锁；
- CPU 和 IO；
- buffer pool；
- 主从延迟。
如果应用 CPU 不高，但数据库 CPU 或慢 SQL 很高，重点排查数据库。
五、看缓存 Redis
Redis 瓶颈可能表现为：
- 响应时间升高；
- 热 key；
- 大 key；
- 连接数过高；
- 命中率低；
- 缓存穿透；
- 网络 IO 高。
如果大量请求打到数据库，可能是缓存失效或命中率低。
六、看 MQ
异步链路要看 MQ。
关注：
- 消息积压；
- 消费速度；
- 消费失败；
- 重试次数；
- 死信队列；
- 消费者线程数。
接口返回快，但最终状态延迟，可能是 MQ 消费瓶颈。
七、看网络和网关
网络或网关问题可能导致：
- 连接超时；
- 502/503/504；
- 响应波动；
- 带宽打满；
- Nginx 连接数限制；
- 网关限流。
要区分服务自身慢和网关层慢。
八、看压测机自身
有时瓶颈不在被测系统，而在压测机。
检查压测机：
- CPU；
- 内存；
- 网络带宽；
- JMeter 堆内存；
- 线程数；
- 是否开启大量监听器。
如果压测机资源打满，测试结果不可信。
九、定位路径示例
现象：并发增加到 500 后，TPS 不再上涨，响应时间从 300ms 升到 3s，错误率增加。
排查：
- 看应用 CPU，发现不高；
- 看应用日志，有数据库连接等待；
- 看数据库连接池，连接数打满；
- 看慢 SQL，有订单查询未走索引；
- 优化索引后复测，响应时间下降，TPS 上升。
这就是完整定位闭环。
十、常见错误
- 只看 JMeter 报告；
- 一上来就说数据库慢；
- 不看压测机资源；
- 不区分 HTTP 错误和业务错误；
- 不看日志；
- 没有复测验证；
- 没有保留监控截图和数据。
十一、面试回答模板
如果面试官问“性能瓶颈定位思路”，可以这样回答：
我定位性能瓶颈会先看压测结果趋势，包括响应时间、TPS 和错误率，判断是在什么压力点出现拐点。然后看应用服务器资源，比如 CPU、内存、Load、GC、线程池和连接池。如果应用 CPU 高，可能是代码计算、锁竞争或 GC；如果 CPU 不高但响应慢，可能是在等数据库、缓存、MQ 或外部服务。接着看数据库慢 SQL、连接数、锁等待和索引命中，再看 Redis 热 key、大 key、命中率，MQ 是否积压，网关是否限流。同时也要检查压测机自身资源，避免压测机成为瓶颈。定位后要做优化并复测，形成闭环。
十二、练习清单
- 分析响应时间升高；
- 分析 TPS 上不去；
- 分析错误率升高；
- 看应用 CPU；
- 看数据库慢 SQL；
- 看连接池；
- 看 GC；
- 看 Redis 命中率；
- 看 MQ 积压；
- 写瓶颈定位案例。
性能瓶颈定位不是猜，而是基于现象、指标、日志和复测形成证据链。
配套刷题：
