一個(gè)ASP.NET項目在部署到生產(chǎn)環(huán)境時(shí)，當用戶(hù)并發(fā)量達到200左右時(shí)，IIS出現了明顯的請求排隊現象，發(fā)送的請求都進(jìn)入等待，無(wú)法及時(shí)響應，系統基本處于不可用狀態(tài)。因經(jīng)驗不足，花了很多時(shí)間精力解決這個(gè)問(wèn)題，本文記錄了我查找問(wèn)題的過(guò)程和最后解決方案，供大家參考。
軟硬件環(huán)境：
IBM刀片服務(wù)器，Intel至強處理器，4物理核，16個(gè)邏輯核心，內存32G
Windows Server2008 Enterprise R2， ASP.NET 4.0 Webform IIS7.5 集成模式
當發(fā)現請求明顯延遲，沒(méi)有被即時(shí)處理的現象，首先就要查看Windows自帶的性能日志Performance Monitor。
由于我注意到只有對于.aspx或.ashx的請求才會(huì )延遲，而.htm或.jpg文件都是即時(shí)響應的，所以很明顯問(wèn)題出在A(yíng)SP.NET上，于是我選擇了性能監視器中的ASP.NET 4.0中的2個(gè)主要計數器：Requests Current（當前請求數）, Requests Queued（被排隊的請求數）進(jìn)行觀(guān)察。通過(guò)觀(guān)察發(fā)現，當前請求數達到200左右時(shí)，被排隊的請求數就從0開(kāi)始上升，一直到50左右，如果請求數繼續上升，則被排隊數也隨之上升。當被排隊的請求數>0時(shí)，就意味著(zhù)這個(gè)時(shí)候去訪(fǎng)問(wèn)任何.aspx頁(yè)面，頁(yè)面都會(huì )處于長(cháng)時(shí)間等待中，沒(méi)有任何響應，直到IIS處理完了其他請求，才會(huì )開(kāi)始處理隊列中的請求。也就是說(shuō)，當排隊數長(cháng)期>0時(shí)，系統基本處于不可用的狀態(tài)。
由于這個(gè)系統的頁(yè)面布局比較復雜，采用了大量的Ajax+.ashx的方式，將內容分批展示在頁(yè)面上，所以對服務(wù)器的請求總數會(huì )比傳統aspx模式來(lái)的多一些，一個(gè)頁(yè)面全部加載完畢可能需要5-10秒，但我想這不應該是造成問(wèn)題的主要原因，就算系統性能較差，IIS也應該足以承受這么小的并發(fā)量的。
為探究到底是系統寫(xiě)的有問(wèn)題，還是IIS本身的問(wèn)題，我拋開(kāi)我們的系統，寫(xiě)了一個(gè)簡(jiǎn)單的頁(yè)面，就一個(gè)aspx文件，page_load里sleep 10秒。假設這就是一個(gè)性能比較差的網(wǎng)站，每個(gè)頁(yè)面都要10秒才能展現，我將其部署在IIS上測試其性能，我使用的是Microsoft Web Application Stress Tool，模擬發(fā)起80個(gè)線(xiàn)程，每個(gè)連接有4個(gè)Socket，總共相當于320個(gè)并發(fā)請求。
測試開(kāi)始后，可以從下圖中看到，當前請求數立刻攀升到300左右（圖中紅線(xiàn)），然后隊列中的請求數也上升到300左右（圖中綠線(xiàn)），就是說(shuō)在300個(gè)并發(fā)請求下，幾乎所有的請求都被排隊了，系統基本不可用，通過(guò)簡(jiǎn)單的測試，這個(gè)問(wèn)題已經(jīng)得以重現了。
隨著(zhù)時(shí)間推移，發(fā)現綠線(xiàn)慢慢減少，從300下降到100多，就是系統可用性漸漸提高，有一部分用戶(hù)可以正常使用，但大部分還在排隊。
過(guò)了6，7分鐘，隊列中的請求數下降到0左右，并有一些小幅波動(dòng)。這個(gè)時(shí)候大部分請求可以被正常處理了。 按照這個(gè)現象分析的話(huà)，應該是IIS發(fā)現有大量請求在隊列中，就會(huì )試圖增加處理線(xiàn)程數以滿(mǎn)足要求，但是增長(cháng)速度有些緩慢。
那是不是系統經(jīng)過(guò)了6，7分鐘的適應期之后，以后就一直可以在這個(gè)并發(fā)量下穩定運作了呢？事實(shí)并非如此。我將壓力測試停了幾秒，當服務(wù)器的請求數降為0以后，再重新開(kāi)啟320個(gè)請求的測試，IIS如何表現？從下圖可以看到，只要請求數有明顯上升，則等待隊列又開(kāi)始達到最高值，然后緩慢下降，重復上面的過(guò)程?？偨Y下來(lái)就是，當出現較大并發(fā)時(shí)，IIS的處理請求能力完全跟不上，需要很長(cháng)時(shí)間才能開(kāi)出足夠的線(xiàn)程。
然后我做了一個(gè)測試，看看IIS默認情況到底能承受多少請求而不排隊？似乎是在100個(gè)并發(fā)左右，表現尚可，未出現排隊。
當200個(gè)左右就不行了。
然后我將測試程序從sleep10秒改成3秒，對于一個(gè)應用系統來(lái)說(shuō)，頁(yè)面平均3秒處理時(shí)間的性能該還算比較正常了。但可惜的是，排隊現象與處理時(shí)間并無(wú)太大關(guān)系，排隊仍然很?chē)乐亍?/p>
針對以上問(wèn)題，查閱了相關(guān)資料，是否出現排隊是和應用程序池的可用線(xiàn)程有關(guān)，通過(guò)2個(gè)方法可以查看系統總線(xiàn)程數和當前可用線(xiàn)程數。
ThreadPool.GetAvailableThreads( out availableWorker, out availableIO);
ThreadPool.GetMaxThreads(out maxWorker, out maxIO);
在隊列請求數達到120左右時(shí)，通過(guò)此方法，得到maxWorker=1600，而availableWorker=1472
因為服務(wù)器是16核的，ASP.NET4.0默認每核可以使用100個(gè)線(xiàn)程，所以maxWorker是1600，1600-120=1480，大致相等。
就是說(shuō)當前有120個(gè)線(xiàn)程被用來(lái)處理請求，還有1400多個(gè)處于空閑。關(guān)鍵問(wèn)題就是為什么這些空閑線(xiàn)程沒(méi)有被及時(shí)啟用？
ASP.NET提供的線(xiàn)程配置參數中，有一個(gè)參數是非常重要，但是可能被大家忽略的，就是minWorkerThreads。
意指最小工作線(xiàn)程，根據我們以上的測試結果，IIS托管線(xiàn)程啟動(dòng)非常慢，微軟也認識到了這個(gè)問(wèn)題，所以提供此參數用于設置正常情況下的最小工作線(xiàn)程數。比如我們系統白天的并發(fā)在200-300之間，則可以設置最小線(xiàn)程為300，這樣系統響應速度可以大幅提高。
據此，我對配置文件（machine.config）進(jìn)行了如下修改。注意都是針對單個(gè)CPU的，系統會(huì )自動(dòng)乘以邏輯CPU的數量。
<system.web>
<processModel autoConfig="false" maxWorkerThreads="200" minWorkerThreads="50" />
相當于最小工作線(xiàn)程設置成了50*16=800。
重啟IIS后進(jìn)行測試，我們得到了以下結果：
可以看到，由于設置了合理的最小工作線(xiàn)程數，使得IIS無(wú)需不斷創(chuàng )建新線(xiàn)程來(lái)處理請求，系統的響應能力已可以滿(mǎn)足并發(fā)要求。
除此之外，在IIS6之后引入了一個(gè)新功能叫Web Garden，其設計目的是為了在CPU占用較低，但是并發(fā)請求數比較多的情況下，提升服務(wù)器性能。這正符合我當前的情況，于是我啟用了Web Garden，將工作進(jìn)程數從1調整到5，在任務(wù)管理器中可以看到w3wp進(jìn)程從原來(lái)的1增加到了5，然后重新測試。
同樣的320個(gè)請求下，可以看到除了一開(kāi)始的幾秒出現了一些排隊，后面基本上表現良好，沒(méi)有請求進(jìn)入隊列。
通過(guò)以上兩種方式，都可以有效解決本文開(kāi)頭提出的問(wèn)題。但Web Garden是工作在多進(jìn)程模式下，如果應用中用到了依賴(lài)進(jìn)程的Session和Cache等對象都必須另想辦法，不能保存在服務(wù)器內存中，而且Web Garden的多個(gè)進(jìn)程切換時(shí)會(huì )有上下文復制，其資源消耗相對單進(jìn)程要大，這些是需要考慮的因素。
聯(lián)系客服
