4、接口响应时间测量方法：如何精确测量端到端延迟，区分网络、服务端、数据库耗时

你发现没有？很多接口问题其实不是代码写错了，而是时间花在了你完全没想到的地方。有一次我排查一个慢接口，业务逻辑跑下来才 20ms，但整体耗时 1.2 秒。你猜花在哪了？网络抖动 + 数据库连接池排队。从那以后，我养成了一个习惯：测量延迟一定要拆开看。

这章我就把常用的测量手段和工具串一遍。说白了，就是帮你在接口调用的路径上插几个测量桩，然后分清每一段到底是谁在拖后腿。

端到端耗时：从客户端发起请求

我个人习惯先用 curl 的 -w 参数做快速探测。你可以这样写：

curl -o /dev/null -s -w "\ntime_total: %{time_total}s\n"
  "time_namelookup: %{time_namelookup}s\n"
  "time_connect: %{time_connect}s\n"
  "time_starttransfer: %{time_starttransfer}s\n"
  "http_code: %{http_code}\n" https://your-api.com/endpoint

你看，输出里 time_total 就是端到端时间。time_starttransfer 是服务器开始返回第一个字节的时刻，它减去 time_connect 基本就是服务端处理时间（不含响应体传输）。

网络耗时：拆开看连接和传输

网络耗时其实是个组合概念。我记得有一次查一个跨地域接口，DNS 解析就花了 800ms。我建议按下面这几层拆：

• DNS 解析 —— 用 dig 或 nslookup 看响应时间
• TCP 连接 —— 用 ping 测 RTT，但更准的是抓包看三次握手
• TLS 握手 —— 用 openssl s_time 或 Wireshark 看
• 数据传输 —— 可用 iperf 测带宽，但接口场景下直接看 time_starttransfer - time_connect

服务端耗时：应用层埋点是最可靠的方式

要精确拿服务端自己的处理时间，必须从应用内部打点。我常用的方案分三层：

1. 中间件/过滤器埋点 —— 在请求入口和出口各记一个时间戳
2. 业务逻辑分段计时 —— 比如调用外部服务一段、本地计算一段，用 Stopwatch 或 System.nanoTime()
3. APM 工具全景追踪 —— 如 SkyWalking、Pinpoint、Datadog，自动给每个 Span 标耗时

你想想看，如果只依赖客户端测到的端到端时间，服务端内部到底哪段慢了你完全不知道。我踩过的坑是：有一次接口总耗时 3 秒，客户端看服务端返回挺快，实际是日志输出太多 IO 阻塞了事件循环。这种只有服务端侧埋点才能发现。

代码示例（Java 伪码）：

long start = System.nanoTime();
try {
    // 业务逻辑
} finally {
    long elapsed = (System.nanoTime() - start) / 1_000_000;
    logger.info("接口处理耗时: {}ms", elapsed);
}

数据库耗时：别只看慢查询日志

数据库耗时的测量，说白了分两步：

三阶段对比：一张表说清测量工具与时机

嗯，这里要注意：测量一定要在真实流量或接近真实的压测场景下进行。本地开发环境网络延迟几乎为零，测出来的数据没有参考价值。