IIS連接數 常識： 虛擬主機會限制IIS連接數，關於其含義，差不多每個主機供應商都有一套自己的說法，微軟也沒有給出很明確的解釋； 含義： IIS伺服器可以同時容納客戶請求的最高連接數，準確的說應該叫“IIS限制連接數”； 一次連接： 1．網站html請求，html中的圖片資源，html中的腳本資源 ...
IIS連接數
常識：
虛擬主機會限制IIS連接數，關於其含義，差不多每個主機供應商都有一套自己的說法，微軟也沒有給出很明確的解釋；
含義：
IIS伺服器可以同時容納客戶請求的最高連接數，準確的說應該叫“IIS限制連接數”；
一次連接：
1．網站html請求，html中的圖片資源，html中的腳本資源，其他需要連接下載的資源等等,任何一個資源的請求即一次連接（雖然有的資源請求連接響應很快）
2．如果網頁採用框架（框架內部嵌套網頁請求），那麼一個框架（iframe）即一次連接
3．如果網頁彈出視窗（視窗內部嵌套網頁請求），那麼一個視窗一個連接
因此，限制連接數即為虛擬主機供應公開的IIS連接數標準，如果購買的IIS連接數為50,那麼我們不得不考慮網站的內容框架和訪問量。
然而同，事實上，很多企業門戶網站訪問量低的驚人，IIS連接數為50也是綽綽有餘了。
設置位置：
IIS（6.2版本，以下所有截圖均此版本）中 “點擊網站”->“右擊切換到功能視圖”->“選中一個網站”->“點擊界面右側的‘限制’鏈接”->“編輯網站限制”
雖然伺服器中可以規定每個站點的最大連接數，但同時也存在伺服器的總計最大連接數。所以，即使規定用戶站點的最大連接數為不限，當伺服器達到了最大連接數時，仍不能訪問站點。而伺服器的最大連接數一般在1000——2000。
IIS併發連接數
設置位置：“選中一個網站”->“高級設置”->"限制"->"最大併發連接數"
預設最大併發連接數為：4294967295，這是一個很驚人的數字！那麼問題來了：
1. 很多虛擬主機供應商所說的無併發連接數限制真的成立嗎？
2. 每個連接的處理，IIS都會開啟一個線程去處理，假設這個處理方式成立，那麼4294967295個併發連接請求來了是否IIS會立即啟動4294967295個線程去處理？
對於1：很顯然不成立，最大併發連接數的設置絕對有上限
對於2：這是很多朋友的誤區，假設4294967295併發連接同時來了，IIS不會立即啟動4294967295個線程去處理，因為這不現實，對於處理連接，IIS是有“最大併發工作線程數”限制的，該數字跟操作系統相關，win7系統的IIS的值是10（或者其他不確定），VS2012自帶的IIS Express的值是80。對於windows伺服器版本的系統的具體值不清楚，即4294967295個併發連接來了後，（這邊以win7下的10為例，假設隊列長度為0），iis第一時間只能啟動10個工作線程去處理，那麼其他4294967285必須排隊，排隊對用戶的體驗來說就是網頁正在載入，但是什麼都不顯示，然後此時購買了據虛擬主機供應商所說的無併發連接數限制的客戶就要開始狂暴了，為何購買了所謂的“無限併發連接數”，還是會一直在載入的情況，我只能說這就是IIS處理能力有限的問題了。然而隊列以外的就會直接返回“HTTP Error 503. The service is unavailable.”
IIS最大併發工作線程數
這個在上面有所涉及，簡單的說就是IIS在併發連接請求過來時的處理機制，它會更機智的以某個數量級為單位來分批處理，讓沒有處理連接請求排隊等待，用戶瀏覽器中對於排隊等待的響應就是“正在載入”，這比頁面直接顯示“HTTP Error 503. The service is unavailable.”更加能讓人接受，但是切勿氣急敗壞的怒點刷新按鈕，因為點的越多，你的請求在排隊隊伍中越靠後。
當然很多朋友會說，為什麼我有時候第一次刷不出來，重新多刷一次內容就出來了，
可能是：
1、頁面腳本哪個地方下載或者處理出了問題，導致頁面顯示異常或者直接不顯示
2、你重新刷新的那個秒級別的操作，web伺服器更快速的已經處理好了其他隊列的請求或者他人放棄了對web伺服器連接請求的操作
3、路由或者寬頻網路運營商問題（不穩定）
4、瀏覽器或者本身電腦問題
我不知道“IIS最大併發工作線程數”有無地方可以設置，知道的朋友可以給我留言，謝謝
那麼現在問題來了，最大併發連接數，影響了排隊的數量，那麼有沒有進步影響排隊數量的設置? 有的：隊列長度
隊列長度
1. 概念：即允許排隊最大連接數限制，但實際允許的最大排隊長度限制，還受IIS連接數限制設置的限制，二者取小。
2. 設置：找到網站的所屬應用程式池，“右擊高級設置”->"常規"->"列隊長度"，預設是1000，可設範圍是10-65535 之間。
最大工作進程數
Web園：
IIS 6.0允許將應用程式池配置成一個Web園（Web Garden），即最大工作線程數大於1的情況，當伺服器的負載較小，不需要額外的工作進程時，IIS 6.0在一定的時間後（預設20分鐘，可配置）自動縮減實際的工作進程數量；如果負載變大，需要額外的工作進程，IIS 6.0再次增加工作進程數量。這一切操作都自動進行，不需要管理員干預。
設置位置：
找到網站的所屬應用程式池，“右擊高級設置”->"進程模型"->"最大工作進程數"，預設1，最大可以設置為4000000：
註意事項：
設置依據
按照每工作進程能承載30個併發的原則來確定應用程式池的最大工作進程數。同時要註意，每個工作進程大約會占用200M左右的系統記憶體，在設置最大工作進程數的時候，要主要最大工作進程數與200M的乘積不要超過系統最大可用記憶體數。一般情況下，建議按照每次增加5個工作進程數的方式對最大工作進程數進行調整，調整完後對網站觀察一段時間，如依然無法滿足要求，再繼續增加5個工作進程數。
session共用問題
如果網站沒有用到session機制，則不會引發此問題。如果用到了session機制進行傳值和保存數據，則需要考慮在應用程式池多個工作進程間進行session共用，防止出現session丟失的問題。存儲方式選用StateServer或者SQLServer會更好，另外多個工作進程切換時會有上下文複製，這也是資源消耗更多地方。
合理的資源回收機制
大多數應用系統都存在工作時間使用量高、非工作時間使用量低的情況，針對這種現象，在系統非忙時應合理的釋放操作系統資源，因此，應合理設置應用程式池的【限制超時】和【回收時間間隔】屬性。
【小結】併發能力 = 實際隊列長度限制（隊列長度限制與IIS連接數限制取小）* 最大工作進程數
詳細參考鏈接：http://www.cnblogs.com/yinhaichao/p/4060209.html
