IIS易混概念小結

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.」更加能讓人接受，可是切勿氣急敗壞的怒點刷新按鈕，由於點的越多，你的請求在排隊隊伍中越靠後。

　　固然不少朋友會說，爲何我有時候第一次刷不出來，從新多刷一次內容就出來了，

　　多是：

　　一、頁面腳本哪一個地方下載或者處理出了問題，致使頁面顯示異常或者直接不顯示

　　二、你從新刷新的那個秒級別的操做，web服務器更快速的已經處理好了其餘隊列的請求或者他人放棄了對web服務器鏈接請求的操做

　　三、路由或者寬帶網絡運營商問題（不穩定）

　　四、瀏覽器或者自己電腦問題

　　我不知道「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