IIS 之 串連數、並發串連數、最大並發背景工作執行緒數、隊列長度、最大背景工作處理序數

標籤：mod   啟動方式   修改註冊表   間隔   地方   發送   儲存資料   tcpip   log   

一、 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也是綽綽有餘了。

二、 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（隊列中的20-90）個請求也會立刻返回“HTTP Error 503. The service is unavailable”，IIS 預設隊列長度設定是1000，範圍在10-65535 之間。

五、 最大背景工作處理序數

　　IIS 6.0 及以後允許將應用程式集區配置成一個Web園（Web Garden）。每個應用程式集區的單一背景工作處理序，能夠大約承受30-50個左右的並發。

　　“應用程式集區” → 找到網站的所屬應用程式集區 → 右鍵“進階設定...” → “進程模型” → “最大背景工作處理序數”，預設值為1。

　　

　　如果這個值大於 1，那麼當有串連請求時會啟動多個新的背景工作處理序執行個體，可開機最多進程數為所指定的最大背景工作處理序數，後續更多的請求將以迴圈的方式發送至背景工作處理序，這樣每個背景工作處理序都能承擔負載一些串連請求，當然是以消耗cpu等硬體做代價，這是值得的，如果web伺服器cpu使用率很低但是又需要更高效的處理並發串連請求，應當這樣做。

　　如果網站中用到了依賴進程的Session和Cache等對象，則不能儲存在伺服器記憶體中，儲存方式選用StateServer或者SQLServer會更好，另外多個背景工作處理序切換時會有上下文複製，這也是資源消耗更多地方。

　　1、 最大背景工作處理序數值的設定依據

　　在確定每個應用程式集區的最大背景工作處理序數時，最主要參考的資料包括網站的最大並發使用者數以及WEB伺服器的可用記憶體數。最大並發使用者數需要通過一段時間的觀察，記錄下在系統忙時的最大並發使用者數，按照每背景工作處理序能承載30個並發的原則來確定應用程式集區的最大背景工作處理序數。同時要注意，每個背景工作處理序大約會佔用200M左右的系統記憶體，在設定最大背景工作處理序數的時候，要主要最大背景工作處理序數與200M的乘積不要超過系統最大可用記憶體數。一般情況下，建議按照每次增加5個背景工作處理序數的方式對最大背景工作處理序數進行調整，調整完後對網站觀察一段時間，如依然無法滿足要求，再繼續增加5個背景工作處理序數。

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

　　3、 合理的資源回收機制

　　大多數應用系統都存在工作時間使用量高、非工作時間使用量低的情況，針對這種現象，在系統非忙時應合理的釋放作業系統資源，因此，應合理設定應用程式集區的【限制逾時】和【回收時間間隔】屬性。

六、總結

　　當很多請求同時到來的時候，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利用率只有百分之幾的話，調整這個數值需要特別注意每一個背景工作處理序是獨立的應用程式，全域靜態變數不共用。

 

IIS 之 串連數、並發串連數、最大並發背景工作執行緒數、隊列長度、最大背景工作處理序數