自從4月28日我們從ASP.NET線程的角度對“黑色30秒”問題進行分析之后，我們采用了新的線程設置，然后觀察“黑色30秒”是否再次出現。
<processModel enable="true" requestQueueLimit="5000" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" minIoThreads="50"/>
采用以上設置之后，Requests Queued出現的頻率的確少了。之后的幾天，也沒出現“黑色30秒”。
於是，ASP.NET線程設置問題引起“黑色30秒”的可能性已經提升到了99.9%，對阿里雲的懷疑只剩下0.1%。
但是：
1. 上次的總結中提到“如果把'黑色30秒‘問題歸因於ASP.NET線程問題，除了30秒左右的這個時間，其他問題表現都得到了更合理的解釋。”，評論中也有朋友提到“不像是這個問題。為什么是30秒而不是20秒，或者50秒？”，這個最顯著的特征卻一直找不到合理的解釋，讓人無法划上圓滿的句號。
2. 之前觀察的階段處於五一假期前夕，流量有所下降，沒有出現真正的訪問高峰，所以需要通過這周的訪問高峰進行驗證。當阿里雲客服想結束工單時，我們說還需要這周的觀察。
。。。
結果，今天下午神奇的“黑色30秒”再次降臨，而這次“黑色30秒”期間沒有出現Requests Queued，請看以下的Windows性能監視器的監視情況。
這次只看4個指標：Requests Executing，Processor Time，Request Execution Time，Current Connections。
1. Requests Executing如過山車
這是這次“黑色30秒”期間最最顯著的表現。
2. CPU先抑后揚
3. Request Execution Time在玩蹦極
4. Current Connections有點像撐桿跳
5. 4個指標的疊加
從上面的表現來看，很明顯，“黑色30秒”期間正在執行的請求卡住了，或者更准確地說正在執行請求的線程卡住了。
與之前的表現（如下圖Requests Queued的上升）相比，這次似乎是新的情況。
根本不是！這只是同一個問題在不同條件下的表現——
之前由於線程設置的少，所以當當前處理請求的線程卡住后，后續的請求只能排隊。
而這次當當前處理請求的線程卡住后，后續的請求過來時，ASP.NET可以有更多空閑線程處理這些請求，而在請求處理過程中這些線程也卡住了，所以表現為Requests Executing飆升。
現在我們猜測“黑色30秒”的觸發條件是在高並發下線程突然卡住了。
為什么線程會卡住？為什么會是30秒？應用程序的原因，Windows的原因，還是阿里雲的原因？大家可以投投票。
如果您對Xen有研究，期待您從dom0 CPU調度策略角度分析可能的原因。