最近幾天線上環境在使用時出現了一些奇怪的現象，用戶訪問某個請求頁面的時候，經常會出現白屏或者是卡頓的情況，通過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的問題，一定要從幾個方面去入手，找到爲何慢的原因，才能知道下一步的解決辦法。