IIS：鏈接數、併發鏈接數

IIS：鏈接數、併發鏈接數、最大併發工做線程數、應用程序池的隊列長度、應用程序池的最大工做進程數詳解

 

 

iis性能指標的各類概念：鏈接數、併發鏈接數、最大併發工做線程數、應用程序池的隊列長度、應用程序池的最大工做進程數詳解,感興趣的同窗參考下。

通常購買過虛擬主機的朋友都熟悉購買時，會限制IIS鏈接數，這邊先從普通不懂代碼用戶角度理解IIS鏈接數

顧名思義即爲IIS服務器能夠同時容納客戶請求的最高鏈接數，準確的說應該叫「IIS限制鏈接數」

這邊客戶請求的鏈接內容包括：

一、網站html請求，html中的圖片資源，html中的腳本資源，其餘須要鏈接下載的資源等等,任何一個資源的請求即一次鏈接（雖然有的資源請求鏈接響應很快）

二、若是網頁採用框架（框架內部嵌套網頁請求），那麼一個框架即一次鏈接

三、若是網頁彈出窗口（窗口內部嵌套網頁請求），那麼一個窗口一個鏈接

虛擬主機供應商在IIS（6.2版本，如下全部截圖均此版本）中  「點擊網站」->「右擊切換到功能視圖」->「點擊界面右側的‘限制’連接」->「編輯網站限制」

 

限制鏈接數即爲虛擬主機供應公開的IIS鏈接數標準，若是購買的IIS鏈接數爲50,那麼咱們不得不考慮網站的內容框架和訪問量

若是網站圖片夠多，彈窗窗口隨意（可能連時間選擇框、簡單條件篩選框也用彈出新窗口），加上不得已的打開新頁面瀏覽內容，那麼僅僅能容忍10我的同 時操做也很正常，我不會把這個操做描述爲不少網站說的「10同時在線」，這很容易讓人誤解，在用戶的一次請求（表面上多是刷新一次網頁，實際上內部請求 不止一次，事實上不多隻有一次）都完成獲得服務器響應完畢以後，鏈接所有會被釋放，固然在你看到展現的頁面以前，內部嵌套若是有請求圖片等鏈接請求，鏈接 會早早的被釋放

事實上，不少企業門戶網站訪問量低的驚人，IIS鏈接數爲50也是綽綽有餘了

 

IIS併發鏈接數

---

 

「管理網站」->「高級設置」->"限制"->"最大併發鏈接數"

其實，普通用戶常說的「IIS連接數」就是這邊的「最大併發鏈接數」，若是PC端有IIS的朋友，能夠測試上面兩個圖片的設置，是相互影響的

這邊默認最大併發鏈接數爲：4294967295，這是一個很驚人的數字，難道這表明着網站能具備併發執行鏈接數爲4294967295的能力？

這邊我作幾個假設：

一、不少虛擬主機供應商所說的無併發鏈接數限制真的成立嗎？

二、每一個鏈接的處理，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了哦）

總的來講，最大併發鏈接數，影響了排隊的數量，

不少時候須要咱們評估本身的網站的最大併發鏈接數，而後來進行設置最佳數量

 

IIS最大併發工做線程數

---

 

這個在上面有所涉及，簡單的說就是IIS在併發鏈接請求過來時的處理機制，它會更機智的以某個數量級爲單位來分批處理，讓沒有處理鏈接請求排隊等待，用戶瀏覽器中對於排隊等待的響應就是「正在加載」，這比頁面直接顯示「HTTP Error 503. The service is unavailable.」更加能讓人接受，可是切勿氣急敗壞的怒點刷新按鈕，由於點的越多，你的請求在排隊隊伍中越靠後。

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

多是：

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

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

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

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

我不知道「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個工做進程數。