如何解决为什么 TTFB 是 Nginx 总请求时间的 10 倍？
为了减少“初始服务器响应时间”并获得更好的 Google PageSpeed Insights，我一直在尝试优化 4.5Kb 请求的响应时间，这需要大约 270 毫秒的 TTFB 和 0.71 毫秒的内容下载（使用 dev 测量）工具）。
该应用托管在印度的 Linode 上，该节点物理上很近。我打开了 Nginx 上的日志，因为我怀疑它有问题，但它显示的总响应时间为 25 毫秒。
鉴于 Nginx 将总响应时间定义为“完整请求时间，从 Nginx 从客户端读取第一个字节开始到 Nginx 发送响应正文的最后一个字节时结束”，我预计最终用户会得到响应时间略高于 25 毫秒，但绝不是 10 倍。
有什么想法我可能会在这里遗漏吗？我还能看什么？
更新：我已决定将我的 Linode 从孟买迁移到新加坡，现在结果要好得多，我从 270 毫秒 TTFB 移动到了大约 100 毫秒。吸取的教训，尽管印度离印度很近，但新加坡的高速互联网使其成为更适合托管我的应用的地方。
解决方法
$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 解析可能会产生影响。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
