为什么 TTFB 是 Nginx 总请求时间的 10 倍？

Question

为了减少 'Initial Server Response Time' 并获得更好的 Google PageSpeed Insights，我一直在尝试优化 4.5Kb 请求的响应时间，该响应时间大约需要 270 毫秒 TTFB 和 0.71 毫秒内容下载（使用开发工具测量）。

该应用程序托管在印度的 Linode 上，该物理位置就在附近。我在 Nginx 上打开了日志，因为我怀疑它有问题，但它显示总响应时间为 25 毫秒。

考虑到 Nginx 将总响应时间定义为 'Full request time, starting when NGINX reads the first byte from the client and ending when NGINX sends the last byte of the response body'，我预计最终用户会在 25 毫秒多一点的时间内收到响应，但绝不会超过 10 倍。

有什么我可能在这里遗漏的想法吗？我还能看什么？

更新： 我已经决定将我的 Linode 从孟买迁移到新加坡，结果现在好多了，我从 270 毫秒 TTFB 移动到 ~100 毫秒。吸取教训，尽管印度很近，但新加坡的快速网速使其更适合托管我的应用程序。

Answer 1

来自nginx logging docs

$request_time – Full request time, starting when NGINX reads the first byte from the client and ending when NGINX sends the last byte of the response body

...NGINX 发送最后一个字节...
这意味着它已将最后一个字节发送到底层 OS。所以 TCP 套接字缓冲区可能已经存储了字节并正在尝试将它们发送到客户端。
Here是对这个场景的分析。

Nginx 不关心客户端和服务器之间的 RTT（往返时间）。这是一个 OS/client 问题。

从客户端 ping 服务器可以让您了解响应时间的顺序。如果 ping 时间大于 nginx 的 $response_time，则性能不能期望接近 $request_time.

ping -c3 -s 1450 www.kernel.org
PING ord.git.kernel.org (147.75.58.133) 1450(1478) bytes of data.
1458 bytes from ord1.git.kernel.org (147.75.58.133): icmp_seq=1 ttl=48 time=191 ms
1458 bytes from ord1.git.kernel.org (147.75.58.133): icmp_seq=2 ttl=48 time=192 ms
1458 bytes from ord1.git.kernel.org (147.75.58.133): icmp_seq=3 ttl=48 time=198 ms

--- ord.git.kernel.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 191.155/194.026/198.468/3.205 ms

作为一个大概的方法，如果您的响应大小为 4.5kB 并且最大 TCP 数据包大小为 ~ 1.5kB，您可以预期总时间最多为 ping 时间的 3 倍。

在 Linux 盒子上最大传输单元 (MTU) 是 1500:

ip addr | grep 'eth0: .*mtu'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

DNS 解析可能有影响。

为什么 TTFB 是 Nginx 总请求时间的 10 倍？

Why is TTFB 10x Nginx total request time?

networking

nginx

linode