軟硬體環境：
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也應該足以承受這麼小的併發量的。
測試開始後，可以從下圖中看到，當前請求數立刻攀公升到300左右（圖中紅線），然後佇列中的請求數也上公升到300左右（圖中綠線），就是說在300個併發請求下，幾乎所有的請求都被排隊了，系統基本不可用，通過簡單的測試，這個問題已經得以重現了。
隨著時間推移，發現綠線慢慢減少，從300下降到100多，就是系統可用性漸漸提高，有一部分使用者可以正常使用，但大部分還在排隊。
過了6，7分鐘，佇列中的請求數下降到0左右，並有一些小幅波動。這個時候大部分請求可以被正常處理了。 按照這個現象分析的話，應該是iis發現有大量請求在佇列中，就會試圖增加處理執行緒數以滿足要求，但是增長速度有些緩慢。
那是不是系統經過了6，7分鐘的適應期之後，以後就一直可以在這個併發量下穩定運作了呢？事實並非如此。我將壓力測試停了幾秒，當伺服器的請求數降為0以後，再重新開啟320個請求的測試，iis如何表現？從下圖可以看到，只要請求數有明顯上公升，則等待佇列又開始達到最高值，然後緩慢下降，重複上面的過程。總結下來就是，當出現較大併發時，iis的處理請求能力完全跟不上，需要很長時間才能開出足夠的執行緒。
然後我做了乙個測試，看看iis預設情況到底能承受多少請求而不排隊？似乎是在100個併發左右，表現尚可，未出現排隊。
當200個左右就不行了。
然後我將測試程式從sleep10秒改成3秒，對於乙個應用系統來說，頁面平均3秒處理時間的效能該還算比較正常了。但可惜的是，排隊現象與處理時間並無太大關係，排隊仍然很嚴重。
針對以上問題，查閱了相關資料，是否出現排隊是和應用程式池的可用執行緒有關，通過2個方法可以檢視系統匯流排程數和當前可用執行緒數。
threadpool.get**ailablethreads( out **ailableworker, out **ailableio);
threadpool.getmaxthreads(out maxworker, out maxio);
在佇列請求數達到120左右時，通過此方法，得到maxworker=1600，而**ailableworker=1472
因為伺服器是16核的，asp.net4.0預設每核可以使用100個執行緒，所以maxworker是1600，1600-120=1480，大致相等。
就是說當前有120個執行緒被用來處理請求，還有1400多個處於空閒。關鍵問題就是為什麼這些空閒執行緒沒有被及時啟用？
asp.net提供的執行緒配置引數中，有乙個引數是非常重要，但是可能被大家忽略的，就是minworkerthreads。
意指最小工作執行緒，根據我們以上的測試結果，iis託管執行緒啟動非常慢，微軟也認識到了這個問題，所以提供此引數用於設定正常情況下的最小工作執行緒數。比如我們系統白天的併發在200-300之間，則可以設定最小執行緒為300，這樣系統響應速度可以大幅提高。
據此，我對配置檔案（machine.config）進行了如下修改。注意都是針對單個cpu的，系統會自動乘以邏輯cpu的數量。
相當於最小工作執行緒設定成了50*16=800。
重啟iis後進行測試，我們得到了以下結果：
可以看到，由於設定了合理的最小工作執行緒數，使得iis無需不斷建立新執行緒來處理請求，系統的響應能力已可以滿足併發要求。
除此之外，在iis6之後引入了乙個新功能叫web garden，其設計目的是為了在cpu占用較低，但是併發請求數比較多的情況下，提公升伺服器效能。這正符合我當前的情況，於是我啟用了web garden，將工作程序數從1調整到5，在任務管理器中可以看到w3wp程序從原來的1增加到了5，然後重新測試。
同樣的320個請求下，可以看到除了一開始的幾秒出現了一些排隊，後面基本上表現良好，沒有請求進入佇列。
通過以上兩種方式，都可以有效解決本文開頭提出的問題。但web garden是工作在多程序模式下，如果應用中用到了依賴程序的session和cache等物件都必須另想辦法，不能儲存在伺服器記憶體中，而且web garden的多個程序切換時會有上下文複製，其資源消耗相對單程序要大，這些是需要考慮的因素。
裝IIS時出現的問題
一 安裝iis發現訊息佇列無法安裝的問題 原因 msdtc服務沒有正常啟動 步驟 1 刪除登錄檔中的鍵 hkey local machine system currentcontrolset services msdtc hkey local machine software microsoft m...
IIS如何確定請求的處理程式
1.給定乙個url請求，iis需要確定它的檔名，副檔名，以及最相似的與本請求資源合適的 scriptmaps metadata 快取的isapi擴充套件 應用程式副檔名對映列表 2.iis檢查是否有設定了的應用程式萬用字元，若有則匹配第一條應用程式副檔名對映 如果這個擴充套件對映返回 我不處理這類請...
如何處理重複請求 併發請求的
你可能會想到的是，只要請求有唯一的請求編號，那麼就能借用redis做這個去重 只要這個唯一請求編號在redis存在，證明處理過，那麼就認為是重複的 string key req12343456788 請求唯一編號 long expiretime 1000 1000毫秒過期，1000ms內的重複請求會...