关于用户访问请求慢,TTFB时间长的问题分析

最近几天线上环境在使用时出现了一些奇怪的现象，用户访问某个请求页面的时候，经常会出现白屏或者是卡顿的情况，通过Chrome开发工具调试查看，发现请求访问过程中，请求中经常会出现某个请求访问时间超长的情况，有时几秒，有时十几秒，有时几百毫秒，时间不等。

其中通过调试获取时间消耗，发现几乎所有的时间都消耗在 TTFB 这个时间节点上。

开始的时候以为是服务的问题，通过对服务的监控，针对访问时间超时比较长的请求查看其请求时间的平均值，结果显示服务器处理请求逻辑的时间都在毫秒范围内，超过1秒的很少，虽然业务逻辑非常复杂但不至于非常耗时。通过对内存量，CPU量，带宽量的查看，服务的各项指标也都在正常的范围内，没有特殊的情况发生。

通过对TTFB的相关信息的搜索，有一篇文章，对TTFB描述的非常详细http://fex.baidu.com/blog/2015/01/chrome-stalled-problem-resolving-process/，这篇文章里，介绍了TTFB时间过长的原因，TTFB实际就是等待响应的时间，具体来说是等待返回首个字节的时间。包含了与服务器之间一个来回响应的时间和等待首个字节被返回的时间。  通过这篇文章的方法，监控某个请求慢的点

发现几乎都是在返回信息的时候发生的延迟，而之前建立连接，握手 SSL等时间都非常短，想来想去，也无法解释为何有时慢有时快的问题，

继续再查询很多介绍TTFB慢的文章，很多都是说 减少DNS，使用CDN，提高服务器性能，等等方法，不断的延展，一个知识套着一个知识点，

甚至分析了各个地区访问服务器的延迟状态。

最终也找不到什么结果。

但在思考了各种情况进行分析后，感觉告诉我，这些文章说的情况，都不是导致这个问题的原因。只好协调运维彻查此事，分析问题有时没有妙招，各种不确定之后，只能采取排除法，截止到现在，如果我不说为什么慢，我敢说你应该打死都想不到。

下一步的操作，只能通过内网访问，直接进到服务，来排除服务的问题了，通过在服务器内网访问，所有的请求都非常的快，未出现访问超时的情况，这再一次坚定了服务没问题的论断，那么问题到底在哪呢？

通过和运维的分析，用户访问一个请求时会经过  智能DNS，云负载均衡器 ---> nginx反向代理 -----> 进到tomcat服务中，返回给用户内容时也是反向的转发给用户。

继续通过排除法，还是内网测试，绕过外面的负载均衡器，直接进入到   nginx --> 进入到tomcat服务的方式，来测试访问速度，果然速度出现了时快是慢的现象，这也又一次坚定了问题出在了nginx上，或者是nginx本身的问题，或者是nginx和tomcat之间出现了问题。

我们再次猜测，怀疑是nginx性能出现了问题，或者是哪里的参数配置有问题，又通过一通的查询，也未找到具体解决办法，只能再辛苦的调试了，我们把静态文件直接放到ngxin上，用过nginx直接访问，发现没有慢的情况，这下范围又缩小了，nginx本身没有问题。

那么问题就出现了在nginx和tomcat之间，但就是这样一个猜测，也多少带偏了一点思路，因为我们怀疑，nginx在指向不同的tomcat服务的时候，网络之间传输存在严重的延迟导致的，我们一个nginx配置了3台服务进行负载，我们挨个试着注释掉每个tomcat服务，查看传输瓶颈在哪里。然后偶然的发现启用了iphash这个nginx策略时，访问就变得很快了，没有延迟，我们又一次的把问题聚焦在iphash上，但清醒下来，我们感觉iphash让某个IP的所有的请求走到了同一个服务服务，这只能说明iphash让请求走到了快的服务上，但这并不是导致请求变慢的原因啊，这样还没有真正找到问题的答案。经过一番的思考，运维提供了一个线索，我们在nginx里虽然反向代理了3个IP服务，但是其中有2个服务是开的1个服务是关的，我们每次都有意的躲避对这台机器的测试，也是明知道这台机子无法访问，这也是唯独忽略的一个现实情况， 这3台tomcat服务器，有一台未开机，因为为了节约成本，在业务繁忙的时候，我们会把服务开启增加机器，而到了晚上不忙的时候，机器会自动停掉，所以表面看着很正常的事，却为TTFB留下了隐患，就这样我们在测试的时候都没有对这个关机的服务的IP地址进行注释，所以当我们关闭iphash，然后配置3个负载的时候，就又会出现慢的情况，我们开了iphash，也是3个负载的时候就正常，问题就这样简单的定位到了负载上，那么问题也肯定不在iphash上，就这样我们去掉了iphash，还是让服务负载到不同的机子上，前面说了，由于请求自动均衡负载，那么是不是请求负载到了这个关机的服务上无法访问，然后自己再去找可以访问的服务，这时候就造成了慢呢，我们果断的注释掉了nginx里，服务关掉的这台机子的反向代理，我天，问题果然好了，每次访问都变快了，最后的结论竟然是，ngxin指向了一个未开机的服务，他自动转到了其他开机的服务上，但就是这样一步让请求变得很慢，等待延迟。这也就是为何启用了iphash就没事了的原因。至此终于找到了问题的原因。所以对于TTFB的问题，一定要从几个方面去入手，找到为何慢的原因，才能知道下一步的解决办法。