針對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