針對Web服務器“黑色30秒”問題（詳見雲計算之路-阿里雲上：Web服務器遭遇奇怪的“黑色30秒”問題），經過分析，我們准備從這個地方下手——為什么會出現\ASP.NET\Request Queued大於0的情況（為什么請求會排隊）？
首先， 通過Windows性能監視器去觀察，看能不能找到這樣的線索——在什么條件下會觸發請求排隊？
我們在性能監視器中增加了1個監視指標——\HTTP Service Request Queues\Arrival Rate
Arrival Rate: Rate at which requests are arriving in the queue
這是一個針對IIS的底層HTTP.SYS的監視指標，從我們的理解，認為它最直接地反映了到達IIS的當前要處理的並發請求。
啟用這個Arrival Rate監視指標后，我們觀察到了1次請求排隊的情況（非“黑色30秒”故障場景）。
上圖中跳起的藍色就表現出現了請求排隊。
我們來逐個指標看一下。
1. HTTP Service Request Queues\Arrival Rate（到達IIS底層的請求）
當時HTTP.SYS收到了465個並發請求。
2. Qequests/Sec(QPS，ASP.NET每秒處理的請求數)
當時ASP.NET的QPS是607。
3. Requests Queued（排隊的請求數）
【注意】出現請求排隊的時間點是11:03:54，而前2個指標高上去的時間點在11:03:55。
【重要線索】由此，我們可以得出這樣的線索：是先出現請求排隊（Requests Queued），然后才出現Arrival Rate與QPS上升。是請求排隊引起Arrival Rate與QPS上升，而不是Arrival Rate與QPS上升引起請求排隊。
接下來通過其他指標驗證這個想法。
4. Current Connections
IIS當前連接數高上去也在出現請求排隊之后。（成功驗證1）
5. CPU
CPU占用也是在出現請求排隊之后才高上去的。（成功驗證2）
【分析結論】請求排隊才是問題的原因，而其他表現只是請求排隊后的結果表現。
那在11:03:54，請求排隊時，其他指標又是什么情況呢？
1. ArrivalRate只有218
2. QPS只有151
3. Current Connections在15以下（具體數值在性能監視器上顯示不出來）
4. CPU占用只有10%
太奇怪了！在請求排隊時，其他指標都處於低點——比正常情況更低的點。
更奇怪的是到達IIS的請求比平時變少了，請求反而排隊了。
【猜想】
從這個監視到的表現看，我們唯一能解釋得通的是：11:03:54，Web服務器似乎在打瞌睡，處理能力全面下降；然后，11:03:55，Web服務器醒了過來，處理能力全面恢復，這時不僅要處理當前的請求，還要處理之前排隊的請求，一下子負載就高了上去。
難道誰給Web服務器下了葯？如果用的是物理機，我們真的會懷疑是誰下的葯？但現在用的是虛擬機，在“被下葯”與“虛擬機問題”之間，哪個更值得懷疑呢？。。。這個問題只能留給阿里雲的同學，我們再怎么懷疑，也只能懷疑而已，無法在虛擬機層面進行驗證。
【進一步的線索】
在寫這篇博客的期間，1台服務器正好發生了“黑色30秒”，看看性能監視器中的相關表現：
1. Arrival Rate與Requests Queued
2. 加上Current Connections
3. 加上CPU
4. 加上Request Execution Time
而且這次接連來了2個“黑色30秒”。
【小結】
虛擬的世界很精彩，虛擬的世界也很無奈。從應用、從Windows的角度，我們真的不知從何處理下手，我們能做的只是找問題的線索。問題的解決可能真的需要阿里雲同學們的努力！