深入理解IIS的多線程工作機制
首先讓我們來看看IIS里面的這2個數字：最大並發連接數，隊列長度。先說這2個數字在哪里看。
最大並發連接數：在IIS中選中一個網站，右鍵網站名稱，在右鍵菜單中找到並點擊【管理網站】->【高級設置】。打開對話框如下圖：
隊列長度：在IIS中選中【應用程序池】，在應用程序池列表中，右鍵你想查看的，在右鍵菜單中選擇【高級設置】。打開如下對話框：
這兩個數字表面上看是影響我們站點的並發處理能力的，但是具體是如何影響一個網站的並發處理能力的呢？要完全理解IIS的並發處理能力，除了這2個數字，實際上還有一個非常關鍵的數字：IIS最大並發工作線程數。
1. IIS最大並發工作線程數
在以前很長一段時間，我一直以為IIS的【最大並發連接數】就是影響IIS最大並發工作線程數。我以為將【最大並發連接數】設置為1萬，那么當1萬個請求同時到來的時候，IIS會開啟1萬個線程進行處理，如果同時到來2萬個請求，由於最大並發連接數只有1萬，那么剩余1萬個請求就會放在隊列里面，當前面的1萬個線程中某個完成了請求之后，再從隊列里面取一個請求。但，這個理解是完全錯誤的，相信很多朋友也跟我有同樣的理解。
現在，首先讓我們來理解什么是【IIS最大並發工作線程數】。這個數字在IIS里面是沒有界面進行設置的，我以前根本就不知道有這個數字。這個數字跟操作系統相關，我的win7系統的IIS的值是10，VS2012自帶的IIS Express的值是80。對於windows服務器版本的系統的具體值是多少沒有測試過，但我猜應該也是有限制的。
這個數字到底是什么意思呢？回到上面舉的例子，當1萬個請求同時進入IIS的時候，由於win7系統的IIS只有10個工作線程，那么這時1萬請求中只有10個請求會在第一時間被處理，剩余9990個請求都需要排隊。也就是說，IIS最多能夠安排10個線程同時處理請求（win7版本的IIS，有的可能是20）。
所以，如果你用自己的win7系統測試IIS的性能的時候，你可能發現，不管你怎么設置【最大並發連接數】，你的IIS處理能力都很有限。
2. 最大並發連接數
上面講的IIS最大並發工作線程數，看上去就是IIS的並發處理能力，如果是這樣，那么【最大並發連接數】有什么意義呢？
還是上面的例子，如果1萬個請求同時到來，而我們的win7系統的IIS最大並發工作線程數只有10，這時如果將【最大並發連接數】設置為100，會有什么效果呢？答案是：只有100個請求會收到正常響應，剩余9900個請求直接返回503（服務不可用）的錯誤。這時，實際上進入排隊等待的只有90個請求。
再換下測試參數，如果將【最大並發連接數】設置為5000，又會有什么效果？答案你可能已經知道了，那就是一開始就有5000個請求直接返回503，剩下5000個請求慢慢正常返回。
這里你看明白了吧，【最大並發連接數】在我們的測試例子中，影響到了排隊的數量。這樣的話，看上去【隊列長度】又不知道什么意思了？
3. 隊列長度
在上面的例子中，如果1萬個請求同時到來，【最大並發連接數】設置為100。這時我們知道，IIS首先會安排那10個線程去處理10個請求，剩下90個請求都需要排隊。這時如果我們將【隊列長度】設置為50，那會出現什么情況？答案是，40個請求會直接返回503服務不可用的錯誤（因為隊列只有50個的長度，剩下的40個就無法排隊了），最終只有60個請求會被正確處理。
讀到這里，你明白了嗎？
結論
當很多請求同時到來的時候，IIS會根據【最大並發連接數】來判斷是否有多余的請求，多余的請求直接返回503，然后再根據【隊列長度】來判斷是否有多余的請求排不了隊，排不了隊的也直接返回503。所以，如何設置【最大並發連接數】和【隊列長度】，實際上是有公式可以計算的：
最大並發連接數 = 隊列長度 + IIS最大並發工作線程數
最后再說說IIS的默認值對我們網站並發處理能力的影響。IIS默認的【最大並發連接數】為4294967295（42億多），而【隊列長度】默認值為1000。對於windows server版本的IIS，最大並發工作線程數可能幾百（猜測，可能沒有限制），按照這個默認值，那么IIS同時處理的請求數也就1000多。1000多這個數字才是IIS真正的並發處理能力，而這個能力跟我們的代碼沒有關系。那么哪些指標是評判我們網站的處理能力的呢？最重要的指標可能莫過於【每秒處理請求數】吧（在性能分析器里面可以查看），這個數字也叫吞吐率。如果每個請求處理速度非常快，那么那么網站吞吐率就大，吞吐率大那么支持的同時在線人數就大。如果要做秒殺，那就看你的秒殺相關的URL支持多大的吞吐率吧。了解了這么多指標，還沒有涉及到CPU的計算能力。CPU的計算能力是如何影響網站的處理能力的呢？還是那么多請求，如果CPU很強大，能夠縮減每個請求的處理時間，那必然會提高吞吐率。還有很多的請求，如果花在網絡傳輸或者到數據庫的傳輸時間比較多，這部分等待時間CPU是閑置的，如果能夠提高CPU的利用率，也可能提高網站的處理能力，最充分的利用服務器的資源。如果不想改代碼而想提高CPU利用率，可以在IIS的應用程序池中設置最大工作進程數（默認值為1），可以設置為10如果當前CPU利用率只有百分之幾的話，調整這個數值需要特別注意每一個工作進程是獨立的應用程序，全局靜態變量不共享。原文:你真的了解：IIS連接數、IIS並發連接數、IIS最大並發工作線程數、應用程序池的隊列長度、應用程序池的最大工作進程數 嗎？
IIS連接數
一般購買過虛擬主機的朋友都熟悉購買時，會限制IIS連接數，這邊先從普通不懂代碼用戶角度理解IIS連接數
顧名思義即為IIS服務器可以同時容納客戶請求的最高連接數，准確的說應該叫“IIS限制連接數”
這邊客戶請求的連接內容包括：
1、網站html請求，html中的圖片資源，html中的腳本資源，其他需要連接下載的資源等等,任何一個資源的請求即一次連接（雖然有的資源請求連接響應很快）
2、如果網頁采用框架（框架內部嵌套網頁請求），那么一個框架即一次連接
3、如果網頁彈出窗口（窗口內部嵌套網頁請求），那么一個窗口一個連接
虛擬主機供應商在IIS（6.2版本，以下所有截圖均此版本）中 “點擊網站”->“右擊切換到功能視圖”->“點擊界面右側的‘限制’鏈接”->“編輯網站限制”
限制連接數即為虛擬主機供應公開的IIS連接數標准，如果購買的IIS連接數為50,那么我們不得不考慮網站的內容框架和訪問量
如果網站圖片夠多，彈窗窗口隨意（可能連時間選擇框、簡單條件篩選框也用彈出新窗口），加上不得已的打開新頁面瀏覽內容，那么僅僅能容忍10個人同時操作也很正常，我不會把這個操作描述為很多網站說的“10同時在線”，這很容易讓人誤解，在用戶的一次請求（表面上可能是刷新一次網頁，實際上內部請求不止一次，事實上很少只有一次）都完成得到服務器響應完畢之后，連接全部會被釋放，當然在你看到展示的頁面之前，內部嵌套如果有請求圖片等連接請求，連接會早早的被釋放
事實上，很多企業門戶網站訪問量低的驚人，IIS連接數為50也是綽綽有余了
這邊給出更加詳細參考鏈接：http://www.west263.com/info/html/IDCzixun/zhujizuyong/20080221/1677.html
IIS並發連接數
“管理網站”->“高級設置”->"限制"->"最大並發連接數"
其實，普通用戶常說的“IIS鏈接數”就是這邊的“最大並發連接數”，如果PC端有IIS的朋友，可以測試上面兩個圖片的設置，是相互影響的
這邊默認最大並發連接數為：4294967295，這是一個很驚人的數字，難道這代表着網站能具有並發執行連接數為4294967295的能力？
這邊我做幾個假設：
1、很多虛擬主機供應商所說的無並發連接數限制真的成立嗎？
2、每個連接的處理，IIS都會開啟一個線程去處理，假設這個處理方式成立，那么4294967295個並發連接請求來了是否IIS會立即啟動4294967295個線程去處理？
對於1：很顯然不成立，最大並發連接數的設置絕對有上限
對於2：這是很多朋友的誤區，假設4294967295並發連接同時來了，IIS不會立即啟動4294967295個線程去處理，因為這不現實，對於處理連接，IIS是有“最大並發工作線程數”限制的，這是我下面要介紹的，我從一些資料上查閱到，該數字跟操作系統相關，win7系統的IIS的值是10（或者其他不確定），VS2012自帶的IIS Express的值是80。對於windows服務器版本的系統的具體值不清楚，即4294967295個並發連接來了后，（這邊以win7下的10為例），iis第一時間只能啟動10個工作線程去處理，那么其他4294967285必須排隊，排隊對用戶的體驗來說就是網頁正在加載，但是什么都不顯示，然后此時購買了據虛擬主機供應商所說的無並發連接數限制的客戶就要開始狂暴了，為何購買了所謂的“無限並發連接數”，還是會一直在加載的情況，我只能說這就是IIS處理能力有限的問題了
當然服務器沒有直接返回“HTTP Error 503. The service is unavailable.”應該也算是一些你花更多錢的安慰吧，因為你只購買了IIS連接數為50的話，那么第50+1個連接請求操作得到的就直接是“HTTP Error 503. The service is unavailable.”了
另外，如果web服務器的硬件設備夠爽朗（牛逼），那么IIS的工作線程也會處理的更快，那么響應的用戶等待的時間也會更短（前提是你的IIS連接數夠大哦，否則就直接503了哦）
總的來說，最大並發連接數，影響了排隊的數量，
很多時候需要我們評估自己的網站的最大並發連接數，然后來進行設置最佳數量
這邊給出更加詳細參考鏈接：
http://www.th7.cn/system/win/201407/63593.shtml
http://blog.csdn.net/shigaofei1/article/details/8222048
IIS最大並發工作線程數
這個在上面有所涉及，簡單的說就是IIS在並發連接請求過來時的處理機制，它會更機智的以某個數量級為單位來分批處理，讓沒有處理連接請求排隊等待，用戶瀏覽器中對於排隊等待的響應就是“正在加載”，這比頁面直接顯示“HTTP Error 503. The service is unavailable.”更加能讓人接受，但是切勿氣急敗壞的怒點刷新按鈕，因為點的越多，你的請求在排隊隊伍中越靠后。
當然很多朋友會說，為什么我有時候第一次刷不出來，重新多刷一次內容就出來了，
可能是：
1、頁面腳本哪個地方下載或者處理出了問題，導致頁面顯示異常或者直接不顯示
2、你重新刷新的那個秒級別的操作，web服務器更快速的已經處理好了其他隊列的請求或者他人放棄了對web服務器連接請求的操作
3、路由或者寬帶網絡運營商問題（不穩定）
4、瀏覽器或者本身電腦問題
我不知道“IIS最大並發工作線程數”有無地方可以設置，知道的朋友可以給我留言，謝謝
那么現在問題來了，最大並發連接數，影響了排隊的數量，那么有沒有進步影響排隊數量的設置? 有的：隊列長度
隊列長度
假設最大連接數設置為100，1000個並發連接請求過來了，首先900直接返回給客戶“HTTP Error 503. The service is unavailable.”
然后IIS先啟動（假設最大並發工作線程數為10）10個線程處理請求，其他90個進入排隊狀態，如果此時如下操作：
找到網站的所屬應用程序池，“右擊高級設置”->"常規"->"列隊長度"，設置為20
那么實際情況又會變成什么樣子呢？只會有20個進入排隊狀態了，70（90-20）個請求也會立刻返回“HTTP Error 503. The service is unavailable”
iis默認隊列長度設置是1000，范圍在10-65535 之間
最大工作進程數
IIS 6.0允許將應用程序池配置成一個Web園（Web Garden）
找到網站的所屬應用程序池，“右擊高級設置”->"進程模型"->"最大工作進程數"，默認1
如果這個值大於 1，那么當有連接請求時會啟動多個新的工作進程實例，可啟動的最多進程數為您所指定的最大工作進程數，后續更多的請求將以循環的方式發送至工作進程，這個每個工作進程都能承擔負載一些連接請求，當然是以消耗cpu等硬件做代價，這是值得的，如果web服務器cpu使用率很低但是又需要更高效的處理並發連接請求，為何不這么做呢？
如果網站中用到了依賴進程的Session和Cache等對象，則不能保存在服務器內存中，存儲方式選用StateServer或者SQLServer會更好，另外多個工作進程切換時會有上下文復制，這也是資源消耗更多地方
最大工作進程數的設置方法：（拷貝）按照每工作進程能承載30個並發的原則來確定應用程序池的最大工作進程數。同時要注意，每個工作進程大約會占用200M左右的系統內存，在設置最大工作進程數的時候，要主要最大工作進程數與200M的乘積不要超過系統最大可用內存數。一般情況下，建議按照每次增加5個工作進程數的方式對最大工作進程數進行調整，調整完后對網站觀察一段時間，如依然無法滿足要求，再繼續增加5個工作進程數。
這邊給出更加詳細參考鏈接：
http://www.itmano.com/87.html
http://www.xuebuyuan.com/174816.html