自從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排程策略角度分析可能的原因。