五秒，可 CPU 只有两成

客户说接口响应五秒，我看监控，CPU 和内存都很轻松，磁盘也不忙。

硬件没压力却这么慢，说明时间花在等，不是花在算，这个判断很关键。

响应时间由什么拼起来

拆开看，才知道找谁，也才知道该不该花钱。

请求到达前有排队，可能排在你自己的网关，也可能排在上游代理，排队时间不算在计算里。

处理阶段包含业务逻辑、数据库查询、外部接口调用，任何一环卡住，整条都慢。

回源和转发也会占时间，尤其是前面挂了一层缓存、命中率又不高的时候。

先用五段把网络排除

排除法比逐项猜省时间，也比开会有用。

用宝塔拨测的网站测速跑多地区多运营商节点，看 DNS、TCP、TLS、TTFB、下载五段。

前面四段都正常、只有 TTFB 大，问题基本在服务端，不必再查线路，也不用换机房。

如果 TCP 或 TLS 就已经偏长，先解决连接，再谈应用，顺序反了就会白改。

TTFB 里再拆一层

到了这一步，才轮到看代码，前面那些都是铺垫。

连接建立后迟迟不返回第一个字节，是「在等」，而等待大多发生在代码之外。

等的原因可能是线程池排满、锁竞争、慢查询、同步调用外部服务，这几种表现一模一样。

这几种都不是加 CPU 能解决的，得看应用日志和慢查询记录，日志里通常写得很清楚。

用分组确认范围

范围对了，方案才不会跑偏，也不会让无辜的人背锅。

所有节点都慢，说明是共性，改应用或架构，别在节点上花时间。

只有部分地区慢，先看链路，别急着改代码，改了别处也感受不到。

平均值正常、最慢节点很差，说明是局部，不需要大动，按局部问题处理就行。

复测与动作

改完能对比，优化才算落地，否则只是感觉上快了。

改完同一组节点连测三次，只比 TTFB 这一段，别的段没动就别拿来说事。

再跑一次业务侧的实际请求，确认不是测速好看、用户仍然慢，这一步经常被跳过。

把每次改动和对应的时间变化记在一起，下次就有参照，也能证明优化确实有效。

响应时间这件事，先分等和算，再谈优化。

分清了，改起来才不费劲。

不费劲，才有多余时间做优化。

做优化，才能把五秒降下来。

降下来，用户才愿意继续用。

愿意用，业务才有结果。

结果好，技术投入才算值得。

值得，才有人继续支持你。

支持多了，事情就好办。

好办的事，才值得长期做。

长期做，才有积累。