无论我们做出什么改变,TTFB都很高! 令人惊讶的是,服务器端的人坚持认为一切都设置正确,服务器运行得足够快,但webpagetest报告根本没有变化! 经过这么多优化后,我无法相信它没有改变,我开始怀疑TLS,gZIP和重定向...... 我错过了什么吗?
答案 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
time_appconnect: 0.921
)time_starttransfer - time_appconnect (1.348 - 0.921 = 0.427)
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设置需要少一趟往返路程)时,每个时序所涉及的内容:
在此示例中,
- 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连接断开之后。