HTTP2,NginX但仍然高TTFB

时间:2016-12-07 08:47:08

标签: ssl nginx http2

无论我们做出什么改变,TTFB都很高! 令人惊讶的是,服务器端的人坚持认为一切都设置正确,服务器运行得足够快,但webpagetest报告根本没有变化! 经过这么多优化后,我无法相信它没有改变,我开始怀疑TLS,gZIP和重定向...... 我错过了什么吗?

2 个答案:

答案 0 :(得分:2)

看起来页面本身需要大约一秒钟才能生成。这是一个卷曲输出(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

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

答案 1 :(得分:0)

使用@ 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协商缓慢以及网络中的某些延迟。

在这里查看这些卷曲时间图形的详细说明:https://blog.cloudflare.com/a-question-of-timing/

  

下图显示了针对典型的TLS 1.2连接上的HTTP(TLS 1.3设置需要少一趟往返路程)时,每个时序所涉及的内容:

     

curl timings variable against a typical HTTP over TLS 1.2 connection

     
      在此示例中,
  • 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连接断开之后。
  •