• IIS：連線數、併發連線數、最大併發工作執行緒數、應用程式池的佇列長度、應用程式池的最大工作程式數詳解

iis效能指標的各種概念：連線數、併發連線數、最大併發工作執行緒數、應用程式池的佇列長度、應用程式池的最大工作程式數詳解,感興趣的同學參考下。

一般購買過虛擬主機的朋友都熟悉購買時，會限制IIS連線數，這邊先從普通不懂程式碼使用者角度理解IIS連線數

顧名思義即為IIS伺服器可以同時容納客戶請求的最高連線數，準確的說應該叫“IIS限制連線數”

這邊客戶請求的連線內容包括：

1、網站html請求，html中的圖片資源，html中的指令碼資源，其他需要連線下載的資源等等,任何一個資源的請求即一次連線（雖然有的資源請求連線響應很快）

2、如果網頁採用框架（框架內部巢狀網頁請求），那麼一個框架即一次連線

3、如果網頁彈出視窗（視窗內部巢狀網頁請求），那麼一個視窗一個連線

虛擬主機供應商在IIS（6.2版本，以下所有截圖均此版本）中  “點選網站”->“右擊切換到功能檢視”->“點選介面右側的‘限制’連結”->“編輯網站限制”

限制連線數即為虛擬主機供應公開的IIS連線數標準，如果購買的IIS連線數為50,那麼我們不得不考慮網站的內容框架和訪問量

如果網站圖片夠多，彈窗視窗隨意（可能連時間選擇框、簡單條件篩選框也用彈出新視窗），加上不得已的開啟新頁面瀏覽內容，那麼僅僅能容忍10個人同 時操作也很正常，我不會把這個操作描述為很多網站說的“10同時線上”，這很容易讓人誤解，在使用者的一次請求（表面上可能是重新整理一次網頁，實際上內部請求 不止一次，事實上很少只有一次）都完成得到伺服器響應完畢之後，連線全部會被釋放，當然在你看到展示的頁面之前，內部巢狀如果有請求圖片等連線請求，連線 會早早的被釋放

事實上，很多企業入口網站訪問量低的驚人，IIS連線數為50也是綽綽有餘了

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了哦）

總的來說，最大併發連線數，影響了排隊的數量，

很多時候需要我們評估自己的網站的最大併發連線數，然後來進行設定最佳數量

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個工作程式數。

• IIS併發連線數及效能優化

如果要檢視IIS連線數，最簡單方便的方法是通過“網站統計”來檢視，“網站統計”的當前線上人數可以認為是當前IIS連線數。然而，“網站統計”的當前線上人數統計時間較長，一般為10分鐘或15分鐘，再加上統計技術及統計機制的問題，從而會產生或多或少的統計誤差。

如果要想知道確切的當前網站IIS連線數的話，最有效的方法是通過windows自帶的系統監視器來檢視。這正是本文要介紹的方法。

一、     新建IIS併發連線數監控器

1.     執行-->輸入“perfmon.msc”

2.     在“系統監視器”圖表區域裡點選右鍵，然後點“新增計數器”

圖一

3.     在“新增計數器”視窗，“效能物件”選擇Web Service，“從列表選擇計數器”選中Current Connection，“從列表選擇例項”選中你要統計的站點，最後點選“新增”按鈕

圖二

二、     設定完畢

這樣，你就可以在“系統監視器”圖表區域中看到一條曲線（此曲線你可以設定其顏色和寬度等引數），它就是網站的IIS連線數曲線圖了，如圖一黃色曲線所示。

需要說明的是，windows系統監視器顯示的是即時IIS併發連線數，並非如“網站統計”那裡的15分鐘內訪問人數，所以你會發現IIS併發連線數並不會太多

• 修改IIS7併發連線數目限制

【更加詳細參考連結】

http://www.itmano.com/87.html

http://www.xuebuyuan.com/174816.html