HTTP2，NginX，但 TTFB 仍然很高

Question

无论我们做了什么改变，TTFB 都很高！ 令人惊讶的是，服务器端的人坚持一切设置正确，服务器运行速度足够快，但webpagetest 报告根本没有改变！ 经过这么多优化，我不敢相信它没有改变，我开始怀疑 TLS、gZIP 和重定向...... 我错过了什么吗？

Answer 1

使用@frederik-deweerdt 的回答和breakdown of curl timing figures

• 您的服务器花费了将近 1 秒的时间进行 TLS 握手 (time_appconnect: 0.921)
• TTFB 是time_starttransfer - time_appconnect (1.348 - 0.921 = 0.427)
• 服务器生成 html 所花费的时间是TTFB - (time_connect - time_namelookup) (0.427 - (0.217 - 0.004)) = 0.214

所以我想说瓶颈不是应用程序，而是服务器缓慢的 TLS 协商和网络中的一些延迟。

在这里查看这些 curl 计时数据的详细解释：https://blog.cloudflare.com/a-question-of-timing/

下图显示了针对典型的 HTTP over TLS 1.2 连接（TLS 1.3 设置需要少一次往返）的每个时间：

• 此示例中的 time_namelookup 需要很长时间。要从图中排除 DNS 解析器性能，您可以解析 cURL 的 IP：--resolve www.zasag.mn:443:218.100.84.167。寻找更快的解析器可能也值得：)。
• time_connect 是从客户端的角度来看的 TCP 三次握手。它在客户端发送 ACK 后立即结束 - 它不包括该 ACK 到达服务器所需的时间。它应该接近服务器的往返时间 (RTT)。在此示例中，RTT 看起来约为 200 毫秒。
• time_appconnect 这里是 TLS 设置。然后客户端就可以发送它的 HTTP GET 请求了。
• time_starttransfer 就在 cURL 从网络读取第一个字节之前（它实际上还没有读取它）。 time_starttransfer - time_appconnect 实际上与此客户端的第一个字节时间 (TTFB) 相同 - 在此示例中为 250 毫秒。这包括网络上的往返，因此您可以通过计算 TTFB - (time_connect - time_namelookup) 更好地猜测服务器在请求上花费了多长时间，因此在这种情况下，服务器仅花费了几毫秒的响应时间，其余时间是网络。 time_total 是在客户端发送 FIN 连接断开之后。

Answer 2

页面本身似乎需要大约一秒钟的时间来生成。这是 curl 输出 (using this to get timestamps)，注意 time_appconnect 的值

$ curl -w "@curl_format.txt" -so /dev/null https://jimmydance.com/
    time_namelookup:  0.004
       time_connect:  0.217
    time_appconnect:  0.921
   time_pretransfer:  0.921
      time_redirect:  0.000
 time_starttransfer:  1.348
                    ----------
         time_total:  1.352

这表明瓶颈是生成页面的应用程序。看看页面本身，应该不会花这么长时间，我会看看你正在使用的框架或分配给服务器的资源。