IIS 之 鏈接數、併發鏈接數、最大併發工做線程數、隊列長度、最大工做進程數

1、IIS鏈接數

　　通常購買過虛擬主機的朋友都熟悉購買時，會限制IIS鏈接數，顧名思義即爲IIS服務器能夠同時容納客戶請求的最高鏈接數，準確的說應該叫「IIS限制鏈接數」。

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

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

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

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

　　不少人對鏈接數的概念認識都很模糊，現介紹以下：
　　[1] 瀏覽者訪問站點，必需與站點經過TCP協議，創建鏈接。這個鏈接在從服務器上讀取信息時存在，讀取結束時，通常即自動關閉。因此，當一個頁面已經徹底地顯示在客戶端的顯示器上時，使用的鏈接也許已經關閉了。
　　[2] 每一個瀏覽者，訪問某站點時，可能會佔用1-3多個鏈接，這是由計算機自動處理的，這樣作的目的是爲了加快速度。因此，對於鏈接數爲30的基礎型主機而言，有時只能十幾我的訪問。
　　[3] 雖然服務器中能夠規定每一個站點的最大鏈接數，但同時也存在服務器的總計最大鏈接數。因此，即便規定用戶站點的最大鏈接數爲不限，當服務器達到了最大鏈接數時，仍不能訪問站點。而服務器的最大鏈接數通常在1000—2000。
　　注意：
　　[1] 這就是爲何服務商勇於開出不限鏈接數的主機，本質上不是無限鏈接數的。
　　[2] 西部數碼提供的主機，容許鏈接數均較高，通常能夠知足用戶需求。

　　在IIS（6.2版及以上版本）中  「點擊網站」->「右擊切換到功能視圖」->「點擊界面右側的 ‘限制...’ 連接」->「編輯網站限制」

　　

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

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

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

2、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了）。

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

3、IIS最大併發工做線程數

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

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

　　多是：

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

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

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

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

　　暫不知道「IIS最大併發工做線程數」有無地方能夠設置。

4、隊列長度

　　最大併發鏈接數，影響了排隊的數量，那麼進一步影響排隊數量的設置就是隊列長度。

　　假設最大鏈接數設置爲100，1000個併發鏈接請求過來了，首先900直接返回給客戶「HTTP Error 503. The service is unavailable.」

　　而後IIS先啓動（假設最大併發工做線程數爲10）10個線程處理請求，其餘90個進入排隊狀態，若是此時以下操做：

　　「應用程序池」 → 找到網站的所屬應用程序池 → 右鍵「高級設置...」 → 「常規」 → 「列隊長度」，設置爲20

　　

　　那麼實際狀況只會有20個進入排隊狀態了，70（隊列中的20-90）個請求也會馬上返回「HTTP Error 503. The service is unavailable」，IIS 默認隊列長度設置是1000，範圍在10-65535 之間。

5、最大工做進程數

　　IIS 6.0 及之後容許將應用程序池配置成一個Web園（Web Garden）。每一個應用程序池的單一工做進程，可以大約承受30-50個左右的併發。

　　「應用程序池」 → 找到網站的所屬應用程序池 → 右鍵「高級設置...」 → 「進程模型」 → 「最大工做進程數」，默認值爲1。

　　

　　若是這個值大於 1，那麼當有鏈接請求時會啓動多個新的工做進程實例，可啓動的最多進程數爲所指定的最大工做進程數，後續更多的請求將以循環的方式發送至工做進程，這樣每一個工做進程都能承擔負載一些鏈接請求，固然是以消耗cpu等硬件作代價，這是值得的，若是web服務器cpu使用率很低可是又須要更高效的處理併發鏈接請求，應當這樣作。

　　若是網站中用到了依賴進程的Session和Cache等對象，則不能保存在服務器內存中，存儲方式選用StateServer或者SQLServer會更好，另外多個工做進程切換時會有上下文複製，這也是資源消耗更多地方。

　　一、 最大工做進程數值的設置依據

　　在肯定每一個應用程序池的最大工做進程數時，最主要參考的數據包括網站的最大併發用戶數以及WEB服務器的可用內存數。最大併發用戶數須要經過一段時間的觀察，記錄下在系統忙時的最大併發用戶數，按照每工做進程能承載30個併發的原則來肯定應用程序池的最大工做進程數。同時要注意，每一個工做進程大約會佔用200M左右的系統內存，在設置最大工做進程數的時候，要主要最大工做進程數與200M的乘積不要超過系統最大可用內存數。通常狀況下，建議按照每次增長5個工做進程數的方式對最大工做進程數進行調整，調整完後對網站觀察一段時間，如依然沒法知足要求，再繼續增長5個工做進程數。

　　二、 session共享問題

　　若是網站沒有用到session機制，則不會引起此問題。若是用到了session機制進行傳值和保存數據，則須要考慮在應用程序池多個工做進程間進行session共享，防止出現session丟失的問題。此問題的解決措施見 Asp.Net 之 Session共享設置。

　　2.1 Asp.Net的Session共享設置

　　Asp.Net提供瞭如下幾種Session保存機制，如表 1所示：Session保存方式

方式名稱	存儲方式	性能
Off	設置爲不使用Session功能	無
InProc	設置爲將Session存儲在進程內，就是ASP中的存儲方式，這是默認值	最高
StateServer	設置爲將Session存儲在獨立的狀態服務中。一般是aspnet_state.exe進程	性能損失10-15%
SQLServer	設置將Session存儲在SQL Server中。	性能損失10-20%
Custom	自定製的存儲方案	由實現方式肯定

　　在Asp.Net程序的web.config配置文件中對Session的保存方式進行設置。若是不顯示指定Session的保存方式，默認使用InProc的方式保存，即Session由提供服務的工做進程保存。

　　爲了提升IIS對高併發的支持，能夠增長應用程序池的工做進程數，IIS會根據內置的調度算法，將用戶的請求在多個工做進程間動態分配，若是搭建了服務器集羣和負載均衡，則用戶請求會在多臺機器的多個工做進程間進行動態分配。在上述狀況下，若是Session的保存方式依然爲InProc，則用戶請求在多個工做進程間切換時可能出現Session丟失的狀況，致使請求失敗或出錯。

　　爲解決上述爲，須要將Session的保存方式設置爲共享，即表 1中的「StateServer」、「SQLServer」或「Custom」方式。這幾種方法中，「SQLServer」方式須要安裝獨立的SQLServer數據庫，「Custom」方式須要自行實現相應的Session存儲與檢索過程，部署起來相對複雜，相對上述兩種方式，「StateServer」方式在功能性和可實施性上最好，所以下文重點介紹此種Session共享機制。

　　2.2 「 StateServer 」設置步驟：

　　[1] 肯定StateServer服務器。若是隻有一臺WEB服務器，可指定當前服務器爲StateServer服務器。若是存在多臺服務器集羣，可指定集羣中的一臺符合較輕的服務器做爲StateServer服務器。

　　[2] 修改註冊表，容許遠程訪問StateServer服務。可直接導入以下腳本。

　　端口默認爲42424，可根據須要進行修改，下文均以42424爲例。

　　[3] 打開【管理工具】-【服務】，找到「Asp.Net State Service」，點擊右鍵，選擇【屬性】，如圖 4所示：

　　[4]在彈出的【屬性】窗口中，將【啓動方式】改成「自動」，而後點擊【啓動】按紐啓動服務，如圖 5所示：

　　[5] 打開待修改網站主目錄下的web.config配置文件，搜索找到「<sessionstate>」配置節點，若是不存在配置節點，則在「<system.web>」節點下新建「<sessionstate>」配置節點，並將節點屬性修改成：
　　<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" />
　　其中「tcpip=*」後的主機IP地址和端口可根據實際狀況修改。修改完後保存配置文件便可。

　　注意：

　　[1] Session中保存的自定義對象必須顯示標記爲可序列化「[serializable]」。若是未顯示標記爲可序列化，則在訪問頁面時會報錯。

　　[2] StateServer服務器必須爲Windows Server操做系統，如Windows Server 2003或Windows Server 2008。

　　三、 合理的資源回收機制

　　大多數應用系統都存在工做時間使用量高、非工做時間使用量低的狀況，針對這種現象，在系統非忙時應合理的釋放操做系統資源，所以，應合理設置應用程序池的【限制超時】和【回收時間間隔】屬性。

6、總結

　　當不少請求同時到來的時候，IIS會根據【最大併發鏈接數】來判斷是否有多餘的請求，多餘的請求直接返回503，而後再根據【隊列長度】來判斷是否有多餘的請求排不了隊，排不了隊的也直接返回503。因此，如何設置【最大併發鏈接數】和【隊列長度】，其實是有公式能夠計算的：

　　最大併發鏈接數 = 隊列長度 + IIS最大併發工做線程數

　　IIS的默認值對咱們網站併發處理能力的影響：

　　IIS默認的" 最大併發鏈接數 "爲4294967295（42億多），而" 隊列長度 "默認值爲1000。對於windows server版本的IIS，最大併發工做線程數可能幾百（猜想，可能沒有限制），按照這個默認值，那麼IIS同時處理的請求數也就1000多。1000多這個數字纔是IIS真正的併發處理能力，而這個能力跟咱們的代碼沒有關係。

　　哪些指標是評判咱們網站的處理能力的呢？最重要的指標可能莫過於" 每秒處理請求數 "（在性能分析器裏面能夠查看），這個數字也叫吞吐率。若是每一個請求處理速度很是快，那麼那麼網站吞吐率就大，吞吐率大那麼支持的同時在線人數就大。若是要作秒殺，那就看你的秒殺相關的URL支持多大的吞吐率吧。

　　CPU的計算能力是如何影響網站的處理能力的呢？仍是那麼多請求，若是CPU很強大，可以縮減每一個請求的處理時間，那必然會提升吞吐率。還有不少的請求，若是花在網絡傳輸或者到數據庫的傳輸時間比較多，這部分等待時間CPU是閒置的，若是可以提升CPU的利用率，也可能提升網站的處理能力，最充分的利用服務器的資源。若是不想改代碼而想提升CPU利用率，能夠在IIS的應用程序池中設置最大工做進程數（默認值爲1），能夠設置爲10若是當前CPU利用率只有百分之幾的話，調整這個數值須要特別注意每個工做進程是獨立的應用程序，全局靜態變量不共享。