當用路過秋天的壓力測試工具重現問題的那一刻，熱淚盈眶！這段時間所承受的一切一涌而出。。。
下面這張圖是首次壓力測試重現問題時的Windows性能監視器截圖，我們對這樣的圖太熟悉了，當它一出現，就知道問題重現了。紅色的直線表示的是100%的CPU占用率，藍色如柵欄的線條是ASP.NET請求執行時間（Request Execution Time）。這時如果用瀏覽器訪問站點，會奇慢無比。
我們是這樣進行壓力測試的，將一台Web服務器從阿里雲SLB（負載均衡）中摘下來，其他運行環境（Web程序、Memcached、NoSQL、RDS）沒有任何變化，然后用壓力測試直接向這台Web服務發出請求。壓力測試工具造成這台雲服務器的TCPv4->Connections Established（性能監視器的一個監測指標）超過2000，問題立即重現。
TCPv4->Connections Established這個指標在我們之前的博文中從沒提過，而它就是今天取得突破的關鍵所在。簡單來說，它表示的是這台服務器的當前TCP連接負載。今天下午我們發現，正常期間Connections Established的數值都在1000以內，而故障期間這個值都會超過1000。在出現故障的時候，只要我們以某種方式將Connections Established的數值降到1000以下，故障就會消失，比如重啟IIS、禁用網卡，甚至重啟Memached/NoSQL服務器（它們與Web服務器之間進行頻繁的TCP連接）也能解決問題。
我們的壓力測試就是針對TCPv4->Connections Established，只要壓到1000以上，問題就會重現；降到1000以下，問題就會消失。（另一張壓測截圖）
為了進一步驗證是這台雲服務器本身的問題，與周邊環境無關。在壓測時這台雲服務器CPU 100%、訪問奇慢無比期間，我們訪問處於同樣環境的其他雲服務器，速度飛快。
根據壓測情況，我們的猜測是：在某種特定的條件下，當雲服務器（Xen虛擬機）的並發TCP連接數超過一定的數值（目前我們的估計是1000~2000），雲服務器的CPU占用率會飆升或大幅波動，某些處理能力會急劇下降，比如ASP.NET的請求處理時間由“幾十毫秒”狂飈至“幾十秒”。（僅是我們單方面的猜測，並不代表阿里雲雲服務器的真實情況）
那我們是如何找到TCPv4->Connections Established的呢？
這要從今天凌晨4點多路過秋天對我們的站點進行短暫的壓測說起。壓測之后，我們發現不僅4台8核的Web服務器的CPU沒撐住，竟然連8核的Memcached服務器的CPU也沒撐住。這說明問題與應用程序沒有關系，如果是應用程序的原因，那不應該出現Memcached服務器CPU撐不住的情況。應用程序與Memcached軟件（Couchbase）都會引起這個問題的可能性估計一萬看才會遇到一次。所以從這個壓測，我們進一步排除ASP.NET應用程序引起這個問題的可能性。
今天上午故障期間，我們特地禁用Memcached/NoSQL進行觀察，問題仍舊。進一步排除了Memcached/NoSQL引起這個問題的可能性。問題與虛擬機的CPU占用高有關，這是板上釘釘的事實，但是究竟什么觸發了CPU占用高比這個事實更重要。CPU不會喝酒喝多了，不會發羊癲瘋。。。肯定是某個因素造成的。
IIS並發連接數是一個嫌疑對象，但很難確定是因為CPU占用高造成IIS並發連接數上升，還是因為IIS並發連接數上升造成CPU占用高。在下午的故障期間，我們發現重啟Memcached/NoSQL竟然也能解決問題，說明問題即使與IIS並發連接數有關，但也不是僅與IIS並發連接數有關。
后來，我們在網上找到了一些說Xen虛擬機TCP處理能力可能存在問題的線索（這只是啟發我們思考問題的線索，不代表現在的Xen虛擬機還存在這個問題）。於是，我們把虛擬機的TCP處理能力作為一個懷疑對象，並在Windows性能監視器中找到一個監測指標——TCPv4->Connections Established，在下午故障期間特地監測了這個指標，才發現前面所說的Connections Established在1000以下一切正常，1000以上就出故障。然后在壓力測試中專門針對這項指標進行測試，才重現了問題。
那如何解決這個問題？
從我們自身角度，我們會想辦法盡量減少單台雲服務器的TCPv4->Connections Established，究竟什么辦法是有效的，需要經過明天訪問高峰期的驗證。
。。。
熱淚盈眶的不僅僅是因為在煎熬中看到了曙光，更是因為給大家帶來這么多這么大的麻煩，總算有了一點交代。
徹底解決這個問題后，我們會以更好的產品、更好的服務去彌補！