调优服务前，先追踪请求路径

一个缓慢的接口，通常不是一段不可拆分的等待，而是一条链路：连接建立、排队、应用处理、存储，以及返回调用方的路程。关键问题不只是“为什么这个请求这么慢？”，而是“这个请求的时间花在了哪里？”

先追踪一个请求

在修改超时配置或增加缓存之前，先挑选一个真实的慢请求，记下它经过的各个阶段。

网关          18 ms
队列         142 ms
应用处理      31 ms
数据库        24 ms
响应           6 ms

在这个例子中，应用函数并不是瓶颈。即使把它的速度提高一倍，也只节省约 15 毫秒，而请求在函数开始执行前仍要等待 142 毫秒。

测量你能控制的边界

在队列、连接池、远程调用和序列化环节添加追踪跨度。记录耗时，也记录能把慢跨度与资源压力联系起来的标识，例如工作线程池、分片、区域或依赖服务。

目标不是制造尽可能高的遥测账单，而是保留足够清晰的边界，让下一次事故排查能够分辨请求是在等待还是在执行。

优化真正变慢的阶段

找到慢阶段后，再选择对应的措施。队列延迟可能需要准入控制或增加工作线程；数据库延迟可能需要索引或减少往返；网络连接开销可能需要复用连接。

如果不先拆解链路，性能优化就容易变成一连串看似合理的猜测。追踪记录能把猜测落到具体位置。