一、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利用率只有百分之幾的話，調整這個數值需要特別注意每一個工作進程是獨立的應用程序，全局靜態變量不共享。