在這篇博文中，我們拋開(kāi)對(duì)阿里云的懷疑，完全從ASP.NET的角度進(jìn)行分析，看能不能找到針對(duì)問(wèn)題現(xiàn)象的更合理的解釋。

“黑色30秒”問(wèn)題現(xiàn)象的主要特征是：排隊(duì)的請(qǐng)求（Requests Queued）突增，到達(dá)HTTP.SYS的請(qǐng)求數(shù)（Arrival Rate）下降，QPS（Requests/Sec）下降，CPU消耗下降，Current Connections上升。

昨天晚上18:08左右發(fā)生了1次“黑色30秒”，正好借此案例分析一下。

1、為什么Requests Queued會(huì)突增？

最直接的原因是ASP.NET沒(méi)有可用的線程處理當(dāng)前請(qǐng)求。為什么會(huì)沒(méi)有可用的線程呢？ASP.NET可用的線程畢竟是有限的，可能是當(dāng)時(shí)瞬間的并發(fā)請(qǐng)求太多，ASP.NET來(lái)不及創(chuàng)建足夠的線程處理這些請(qǐng)求。

我們來(lái)看一下ASP.NET中線程相關(guān)的設(shè)置——machine.config中的processModel（位于C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config）。

有4個(gè)相關(guān)設(shè)置：maxWorkerThreads（默認(rèn)值是20）, maxIoThreads（默認(rèn)值是20）, minWorkerThreads（默認(rèn)值是1）, minIoThreads（默認(rèn)值是1）。（這些設(shè)置是針對(duì)每個(gè)CPU核）

我們用的就是默認(rèn)設(shè)置，由于我們的Web服務(wù)器是8核的，于是實(shí)際的maxWorkerThreads是160，實(shí)際的maxIoThreads是160，實(shí)際的minWorkerThreads是8，實(shí)際的minIoThreads是8。

基于這樣的設(shè)置，是不是如果瞬間并發(fā)請(qǐng)求是169，就會(huì)出現(xiàn)排隊(duì)？不是的，ASP.NET沒(méi)這么傻！因?yàn)镃LR 1秒只能創(chuàng)建2個(gè)線程，等線程用完時(shí)才創(chuàng)建，黃花菜都涼了。我們猜測(cè)ASP.NET只是根據(jù)這個(gè)設(shè)置去預(yù)測(cè)線程池中的可用線程是不是緊張，是不是需要?jiǎng)?chuàng)建新的線程，以及創(chuàng)建多少線程。

那什么情況下會(huì)出現(xiàn)“黑色30秒”期間那樣的大量請(qǐng)求排隊(duì)？假如并發(fā)請(qǐng)求數(shù)平時(shí)是300，突然某個(gè)瞬間并發(fā)請(qǐng)求數(shù)是600，超出了ASP.NET預(yù)估的所需的可用線程數(shù)，于是那些拿不到線程的請(qǐng)求只能排隊(duì)等待正在執(zhí)行的請(qǐng)求釋放線程以及CLR創(chuàng)建新的線程。隨著時(shí)間的推移，釋放出來(lái)的線程+新創(chuàng)建的線程足以處理這些排隊(duì)的請(qǐng)求，就恢復(fù)了正常。

那如何驗(yàn)證這個(gè)猜測(cè)呢？ 修改maxWorkerThreads, maxIoThreads, minWorkerThreads, minIoThreads的設(shè)置，讓ASP.NET提供更多的可用線程，目前我們采用的設(shè)置如下：

processModel enable="true" requestQueueLimit="5000" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" minIoThreads="50"/>

如果采用這個(gè)設(shè)置之后，“黑色30秒”現(xiàn)象幾乎不出現(xiàn)，就能驗(yàn)證問(wèn)題出在這個(gè)地方。現(xiàn)在主站www.cnblogs.com已經(jīng)使用了這個(gè)設(shè)置，需要觀察一段時(shí)間進(jìn)行驗(yàn)證。

【啟示】

1) 通過(guò)Windows性能監(jiān)視器監(jiān)視\ASP.NET\Requests Queued可以直觀地評(píng)估ASP.NET應(yīng)用程序的吞吐能力（throughput）。

2) 通過(guò)ASP.NET異步編程（async/await）可以有效減少可用線程緊張?jiān)斐傻恼?qǐng)求排隊(duì)問(wèn)題。

2、為什么Arrival Rate會(huì)下降？

（上圖中的橙色線條）

這是“黑色30秒”問(wèn)題中最讓人不解的地方，ASP.NET中請(qǐng)求再怎么排隊(duì)，怎么會(huì)造成到達(dá)HTTP.SYS的請(qǐng)求數(shù)下降呢？一開(kāi)始我們總是不相信是請(qǐng)求排隊(duì)引起的Arrival Rate下降，但是監(jiān)視圖中卻鐵證如山。

寫(xiě)這篇博客之前，我們突然想通了！之前忽略了一個(gè)地方——當(dāng)你打這篇博文時(shí)，第1個(gè)請(qǐng)求是html頁(yè)面，如果這個(gè)請(qǐng)求得到正常響應(yīng)，瀏覽器在加載這個(gè)頁(yè)面時(shí)會(huì)發(fā)出多個(gè)ajax請(qǐng)求；如果第1個(gè)請(qǐng)求被排隊(duì)，瀏覽器處于等待狀態(tài)，后續(xù)的ajax請(qǐng)求就不會(huì)發(fā)出，這樣到達(dá)HTTP.SYS的請(qǐng)求數(shù)就會(huì)下降。這也解釋了為什么有時(shí)會(huì)在“黑色30秒”的中間階段Arrival Rate會(huì)飆高，正是因?yàn)楫?dāng)時(shí)被排隊(duì)的請(qǐng)求所對(duì)應(yīng)的頁(yè)面中有很多ajax，當(dāng)它結(jié)束排隊(duì)被執(zhí)行后，后續(xù)的很多ajax請(qǐng)求（可能排隊(duì)的很多是這樣的請(qǐng)求）到達(dá)了HTTP.SYS。

于是，我們相信了是請(qǐng)求排隊(duì)引起的Arrival Rate下降。

【啟示】

不能把目光局限于當(dāng)前看到的問(wèn)題表現(xiàn)，而要綜合考慮，將諸多因素聯(lián)系起來(lái)理清各種現(xiàn)象之間的關(guān)系。

3、QPS下降

與Arrival Rate下降同理，QPS(Requests/Sec)與Arrival Rate是直接相關(guān)的，成正比關(guān)系。

于是，QPS下降也是因?yàn)檎?qǐng)求排隊(duì)。

4、CPU消耗下降

也是同理，Arrival Rate與QPS下降，說(shuō)明CPU要干的活少了，自然消耗就下降。

于是，CPU消耗下降也是因?yàn)檎?qǐng)求排隊(duì)。

5、Current Connections上升

Current Connections是請(qǐng)求排隊(duì)的一個(gè)直接表現(xiàn)，請(qǐng)求還沒(méi)被執(zhí)行，連接當(dāng)然會(huì)保持著。

于是，Current Connection上升也是因?yàn)檎?qǐng)求排隊(duì)。

6、看一個(gè)新指標(biāo)Requests Executing

（上圖綠色的線條表示的是Requests Executing）

在請(qǐng)求排隊(duì)的期間，正在被ASP.NET執(zhí)行的請(qǐng)求數(shù)（Requests Executing）在增加，說(shuō)明隨著被釋放出來(lái)的線程增多以及更多的新線程被創(chuàng)建，排列中的請(qǐng)求正在被越來(lái)越多地執(zhí)行。這從側(cè)面說(shuō)明了執(zhí)行中的線程可能是正常的，沒(méi)有被卡住。（接下來(lái)的IIS日志信息會(huì)進(jìn)一步驗(yàn)證這一點(diǎn)）

于是，Requests Executing在增加也是因?yàn)檎?qǐng)求被排隊(duì)，而且說(shuō)明這個(gè)排隊(duì)是正常的，沒(méi)有哪個(gè)地方卡住了。

7、再來(lái)看看IIS日志中請(qǐng)求的time-taken

在“黑色30秒”階段，IIS日志中沒(méi)有time-taken超過(guò)1s的請(qǐng)求！這說(shuō)明了什么？說(shuō)明了正在被執(zhí)行的請(qǐng)求處理速度很快，沒(méi)有什么地方被卡住。。。除了因?yàn)榭捎镁€程不夠，請(qǐng)求被排隊(duì)。

于是，IIS日志說(shuō)明除了請(qǐng)求排隊(duì)，其他地方一切正常。

【總結(jié)】

如果把“黑色30秒”問(wèn)題歸因于ASP.NET線程問(wèn)題，除了30秒左右的這個(gè)時(shí)間，其他問(wèn)題表現(xiàn)都得到了更合理的解釋。

寫(xiě)這篇博客之前，我們當(dāng)時(shí)覺(jué)得ASP.NET線程問(wèn)題引起“黑色30秒”問(wèn)題的可能性是80%，寫(xiě)完這7點(diǎn)分析之后，我們覺(jué)得可能性是99%，除非這次分析的“黑色30秒”與之前的“黑色30秒”不是同一個(gè)問(wèn)題。

現(xiàn)在還需要我們使用新設(shè)置(maxWorkerThreads="100", maxIoThreads="100", minWorkerThreads="50", minIoThreads="50")之后的驗(yàn)證。

大結(jié)局即將來(lái)臨，重要的可能不是結(jié)局是什么，而是其中的過(guò)程，我們分享的也是解決問(wèn)題的過(guò)程。