为什么 TTFB 10 倍 Nginx 总请求时间？答案

【问题标题】：Why is TTFB 10x Nginx total request time?为什么 TTFB 10 倍 Nginx 总请求时间？
【发布时间】：2023-03-03 22:22:01
【问题描述】：

为了减少“初始服务器响应时间”并获得更好的 Google PageSpeed Insights，我一直在尝试优化 4.5Kb 请求的响应时间，该响应时间大约需要 270 毫秒 TTFB 和 0.71 毫秒内容下载（使用 dev 测量工具）。

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

鉴于 Nginx 将总响应时间定义为“完整请求时间，从 NGINX 从客户端读取第一个字节开始，到 NGINX 发送响应正文的最后一个字节结束”，我预计最终用户会得到响应时间略超过 25 毫秒，但绝不是 10 倍。

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

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

【问题讨论】：

标签： nginx networking linode

【解决方案1】：

来自nginx logging docs

$request_time - 完整的请求时间，从 NGINX 读取第一个开始来自客户端的字节并在 NGINX 发送最后一个字节时结束响应正文

...NGINX 发送最后一个字节...
这意味着它已将最后一个字节发送到底层操作系统。所以 TCP 套接字缓冲区可能已经存储了字节并试图将它们发送到客户端。
Here 是对这种情况的分析。

Nginx 不关心客户端和服务器之间的 RTT（往返时间）。这是操作系统/客户端问题。

从客户端 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 解析可能会产生影响。

【讨论】：

谢谢。我已经决定将我的 Linode 从孟买迁移到新加坡，现在结果要好得多，我从 270 毫秒 TTFB 迁移到了 ~100 毫秒。吸取的教训，尽管印度很近，但新加坡的快速互联网速度使其更适合托管我的应用程序。
很高兴它有帮助。如果您考虑的话，您可以接受答案:-)