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

轉載于:https://www.cnblogs.com/yscit/p/8478165.html

總結

以上是生活随笔為你收集整理的IIS易混概念小结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。