TTFB 是 Time to First Byte 的缩写,指的是浏览器开始收到服务器响应数据的时间(后台处理时间+重定向时间),是反映服务端响应速度的重要指标。就像你问朋友了一个问题,你的朋友思考了一会儿才给你答案,你朋友思考的时间就相当于 TTFB。你朋友思考的时间越短,就说明你朋友越聪明或者对你的问题越熟悉。对服务器来说,TTFB 时间越短,就说明服务器响应越快。
因为每个服务器的硬件和网络环境都不尽相同,每个服务器的 TTFB 时间也不相同。如果想知道你的服务器可以优化到什么程度,大家可以上传一些静态的 HTML 页面到服务器,然后打开这些静态页面,看一些这些页面的 TTFB 时间,大多数服务器的 TTFB 时间都在 50 ms 一下,这个时间就是我们优化时候可以追求的时间。下面两个图中的 TTFB 时间分别是本站所在服务器的静态和动态网页 TTFB 等待时间。
根据我们的测试,TTFB 时间如果超过了 500 ms,用户在打开网页的时候就会感觉到明显的等待。我么可以把 500 ms 以上认为是 TTFB 时间过长。可见,WordPress 智库的服务器还不算差。
我们知道,对于动态网页来说,服务器收到用户打开一个页面的请求时,首先要从数据库中读取该页面需要的数据,然后把这些数据传入到模版中,模版渲染后,再返回给用户。由于查询数据和渲染模版需要需要一定的时间,在这个过程没有完成之前,浏览器就一致处于等待接收服务器响应的状态。有些服务的性能比较低,或者优化没做好,这个时间就会比较长。
当然,如果服务器到用户之间的网络不好,(比如,服务器在欧洲,用户在中国,用户打开网页的时候,请求需要跨越千山万水才能达到服务器),服务器接收到用户请求的时间过长,也是导致 TTFB 时间过长的原因。
有时候,页面在用户的浏览器中保存了过多的 Cookie,每次请求,这些 Cookie 都要发送到服务器,服务器都要处理这些 Cookie,这也是导致 TTFB 时间过长的原因之一。
知道了原因,解决办法就显而易见了,那就是缩短服务器响应时间,最简单直接并且有效的办法就是使用缓存,把 PHP 和 MySQL 的执行时间最小化,一些缓存插件可以把 SQL 查询结果缓存起来,把几十次查询结果转换为几次;一些缓存插件可以直接把用户所请求的页面静态化,用户打开网页时,相当于直接从服务器上下载了静态页面。
如果是网络原因,换一个服务器是比较直接的解决办法。如果因为一些原因不能换服务器,可以使用一个 CDN,把页面同步到离用户比较近的 CDN 节点上,也是一个不错的解决办法。
如果是 Cookie 的原因,可以通过修改应用程序,删除一些不必要的 Cookie,或者精简 Cookie 内容,缩短 Cookie 的有效期等,都是解决办法。
记录一个问题吧。
新上线的应用,第一次上线部署了两个节点,通过DMZ的NGINX映射出去的。
上线之后,第三天突然发现访问很慢,有50%的几率保持在7秒左右,通过日志平台观察代码处理时间在40ms左右。
打开F12,发现TTFB时间消耗了6秒。猜测nginx配置有问题,可是nginx配置是我们写好发给运维同事做的,不会出问题。
再猜是DMZ区到应用服务器的防火墙没有打通。最后定位是这个原因。
现象,偶尔访问时间过长,NGINX hash路由 消耗时间过长。
造成原因,NGINX Hash 路由 其中某一台 无法访问,造成迂回访问,消耗时间。(可以通过curl命令直接在服务器上访问,跳过nginx 然后再分析)