一個ASP.NET專案在部署到生產環境時，當用戶併發量達到200左右時，IIS出現了明顯的請求排隊現象，傳送的請求都進入等待，無法及時響應，系統基本處於不可用狀態。因經驗不足，花了很多時間精力解決這個問題，本文記錄了我查詢問題的過程和最後解決方案，供大家參考。

軟硬體環境：

IBM刀鋒伺服器，Intel至強處理器，4物理核，16個邏輯核心，記憶體32G

Windows Server2008 Enterprise R2， ASP.NET 4.0 Webform  IIS7.5  整合模式

當發現請求明顯延遲，沒有被即時處理的現象，首先就要檢視Windows自帶的效能日誌Performance Monitor。

由於我注意到只有對於.aspx或.ashx的請求才會延遲，而.htm或.jpg檔案都是即時響應的，所以很明顯問題出在ASP.NET上，於是我選擇了效能監視器中的ASP.NET 4.0中的2個主要計數器：Requests Current（當前請求數）, Requests Queued（被排隊的請求數）進行觀察。通過觀察發現，當前請求數達到200左右時，被排隊的請求數就從0開始上升，一直到50左右，如果請求數繼續上升，則被排隊數也隨之上升。當被排隊的請求數>0時，就意味著這個時候去訪問任何.aspx頁面，頁面都會處於長時間等待中，沒有任何響應，直到IIS處理完了其他請求，才會開始處理佇列中的請求。也就是說，當排隊數長期>0時，系統基本處於不可用的狀態。

由於這個系統的頁面佈局比較複雜，採用了大量的Ajax+.ashx的方式，將內容分批展示在頁面上，所以對伺服器的請求總數會比傳統aspx模式來的多一些，一個頁面全部載入完畢可能需要5-10秒，但我想這不應該是造成問題的主要原因，就算系統性能較差，IIS也應該足以承受這麼小的併發量的。

為探究到底是系統寫的有問題，還是IIS本身的問題，我拋開我們的系統，寫了一個簡單的頁面，就一個aspx檔案，page_load裡sleep 10秒。假設這就是一個性能比較差的網站，每個頁面都要10秒才能展現，我將其部署在IIS上測試其效能，我使用的是Microsoft Web Application Stress Tool，模擬發起80個執行緒，每個連線有4個Socket，總共相當於320個併發請求。

測試開始後，可以從下圖中看到，當前請求數立刻攀升到300左右（圖中紅線），然後佇列中的請求數也上升到300左右（圖中綠線），就是說在300個併發請求下，幾乎所有的請求都被排隊了，系統基本不可用，通過簡單的測試，這個問題已經得以重現了。

隨著時間推移，發現綠線慢慢減少，從300下降到100多，就是系統可用性漸漸提高，有一部分使用者可以正常使用，但大部分還在排隊。

過了6，7分鐘，佇列中的請求數下降到0左右，並有一些小幅波動。這個時候大部分請求可以被正常處理了。 按照這個現象分析的話，應該是IIS發現有大量請求在佇列中，就會試圖增加處理執行緒數以滿足要求，但是增長速度有些緩慢。

那是不是系統經過了6，7分鐘的適應期之後，以後就一直可以在這個併發量下穩定運作了呢？事實並非如此。我將壓力測試停了幾秒，當伺服器的請求數降為0以後，再重新開啟320個請求的測試，IIS如何表現？從下圖可以看到，只要請求數有明顯上升，則等待佇列又開始達到最高值，然後緩慢下降，重複上面的過程。總結下來就是，當出現較大併發時，IIS的處理請求能力完全跟不上，需要很長時間才能開出足夠的執行緒。

然後我做了一個測試，看看IIS預設情況到底能承受多少請求而不排隊？似乎是在100個併發左右，表現尚可，未出現排隊。

當200個左右就不行了。

然後我將測試程式從sleep10秒改成3秒，對於一個應用系統來說，頁面平均3秒處理時間的效能該還算比較正常了。但可惜的是，排隊現象與處理時間並無太大關係，排隊仍然很嚴重。

針對以上問題，查閱了相關資料，是否出現排隊是和應用程式池的可用執行緒有關，通過2個方法可以檢視系統匯流排程數和當前可用執行緒數。

ThreadPool.GetAvailableThreads( out availableWorker, out availableIO);

ThreadPool.GetMaxThreads(out maxWorker, out maxIO);

在佇列請求數達到120左右時，通過此方法，得到maxWorker=1600，而availableWorker=1472

因為伺服器是16核的，ASP.NET4.0預設每核可以使用100個執行緒，所以maxWorker是1600，1600-120=1480，大致相等。

就是說當前有120個執行緒被用來處理請求，還有1400多個處於空閒。關鍵問題就是為什麼這些空閒執行緒沒有被及時啟用？

ASP.NET提供的執行緒配置引數中，有一個引數是非常重要，但是可能被大家忽略的，就是minWorkerThreads。

意指最小工作執行緒，根據我們以上的測試結果，IIS託管執行緒啟動非常慢，微軟也認識到了這個問題，所以提供此引數用於設定正常情況下的最小工作執行緒數。比如我們系統白天的併發在200-300之間，則可以設定最小執行緒為300，這樣系統響應速度可以大幅提高。

據此，我對配置檔案（machine.config）進行了如下修改。注意都是針對單個CPU的，系統會自動乘以邏輯CPU的數量。

<system.web>
<processModel autoConfig="false" maxWorkerThreads="200" minWorkerThreads="50" />

 相當於最小工作執行緒設定成了50*16=800。

重啟IIS後進行測試，我們得到了以下結果：

可以看到，由於設定了合理的最小工作執行緒數，使得IIS無需不斷建立新執行緒來處理請求，系統的響應能力已可以滿足併發要求。

除此之外，在IIS6之後引入了一個新功能叫Web Garden，其設計目的是為了在CPU佔用較低，但是併發請求數比較多的情況下，提升伺服器效能。這正符合我當前的情況，於是我啟用了Web Garden，將工作程序數從1調整到5，在工作管理員中可以看到w3wp程序從原來的1增加到了5，然後重新測試。

同樣的320個請求下，可以看到除了一開始的幾秒出現了一些排隊，後面基本上表現良好，沒有請求進入佇列。

通過以上兩種方式，都可以有效解決本文開頭提出的問題。但Web Garden是工作在多程序模式下，如果應用中用到了依賴程序的Session和Cache等物件都必須另想辦法，不能儲存在伺服器記憶體中，而且Web Garden的多個程序切換時會有上下文複製，其資源消耗相對單程序要大，這些是需要考慮的因素。