站点部署，IIS配置优化指南
通常把站點發布到IIS上運行正常后，很少會去考慮IIS提供的各種參數，如何配置才是最適合當前站點運行需要的？這篇文章，從基本設置、回收機制、性能、并發、安全性等IIS設置講解應當如何優化。
先來“IIS應用程序池”優化后的參數配置截圖：
圖中一些數值限制參數，可以借助一些工具（如：windows性能監控）觀察站點運行的指標進行設置，具體后面會介紹到
下面來分別解說下這些參數為什么要這樣設置（注：文章中的參數，不是按照應用程序池的設置從上到下排列的，而是按照優化的功能點排列）
按如下圖進行默認參數模板設置，設置后，新建的應用程序池就使用這個默認參數模板。
IIS版本號查看
在iis管理器中->幫助->關于Internet信息服務，如下圖，版本是IIS10.
常規?>?啟動32位應用程序
默認值：False
優化設置：按需設置。如果確認站點依賴一些32位的組件，需將此設置為true。
建議：為?32bit?應用程序的網站單獨創建一個應用程序池
參考：
64位系統上iis運行32位的網站程序
常規?>?托管管道模式
IIS7?應用程序池新增的經典模式和集成模式
經典模式：是為了保留和IIS6一樣的處理方式，以前開發的代碼，可以方便的移植到IIS7上。
集成模式：將ASP.NET請求管道與IIS核心管道組合在一起，這種模式與操作系統結合更緊密，能夠提供更好的性能，能夠實現配置和治理的模塊化，而且增加了使用托管代碼模塊擴展IIS時的靈活性。
優化設置： 改為?Integrated（集成模式）
參考：
????對IIS7經典模式和集成模式的理解
回收?>?固定時間間隔（分鐘）
一個時間段，超過該時間段，應用程序池將回收。值為?0?，則應用程序池不會按固定間隔回收
默認值：1740分鐘，29小時
優化設置：改為0?。因為無法避免在高峰期發生回收。同時設置“回收?>?特定時間”
回收?>?特定時間
應用程序池進行回收的一組特定的本地時間（24小時制）
優化設置：固定在低峰期時回收。eg：設定為?04:00?、15:30?等
另外，也可以使用windows計劃任務實現iis站點每周六晚定時回收
進程模型?>?閑置超時（分鐘）
一個時間段，設定工作進程允許保持閑置狀態的最大時間間隔，超過該時間就會自動關閉。
優化設置：改為0，避免內存信息頻繁被回收清空。同時設置“回收?>?特定時間”
進程模型?>?空閑超時操作
默認是“Terminate”（另一個選項是“Suspend”）。
Terminate?表示一旦超時就終止服務，并回收工作進程的緩沖區的內存；
Suspend?則懸停等待，暫不回收緩沖區內存。
另外：
CPU超限占用安全方案設置
CPU限制并不是用于控制每個進程的CPU利用率，而是一種處理發生CPU超限的工作進程的安全方案，這樣可以避免工作進程占用CPU過久。
參考：
????iis7.0 cpu 限制
iis中對cpu限制的操作：
1.???限制：10000?（以百分比*1000計算，10000則表示10%）
2.???限制操作：1、noaction?無操作?2、KillW3wp?刪除進程 并在限制時間內重新開啟新進程
3.???限制間隔（分鐘）：設置時間限制，多久時間內重啟和檢測
內存超限回收機制
根據實際運行情況設定?"回收?>?虛擬內存限制"?和?"回收?>?專用內存限制"，默認為禁用狀態，一般不用為此專門設定。
開啟|關閉時間限制
根據實際運行情況設定，默認90秒。如上圖，我都設置為了120秒
進程模型?>?關閉時間限制（秒）：為工作進程指定的，完成處理請求并關閉的時間段。如果工作進程超過關閉時間限制，將被終止。
進程模型?>?啟動時間限制（秒）：為工作進程指定的，啟動并進行初始化的時間段。如果工作進程初始化時間超過啟動時間限制，將被終止。
回收?>?禁用重疊回收
默認值?false。應用程序池使用重疊回收方式。在這種方式下，當應用程序池要關閉某個工作進程時，會先創建一個工作進程，直到新的工作進程成功創建后才關閉舊的工作進程；?
設置為?true，則先關閉舊的工作進程，然后再創建新的工作進程。?如果Web?應用程序不支持多實例運行，那么你必須配置應用程序池禁止使用重疊回收方式。
回收?>?生成回收事件條目
IIS事件查看器
方法一：點擊“開始→運行”，輸入eventvwr，點擊“確定”，就可以打開事件查看器。
方法二：單擊“開始”-“設置”-“控制面板”-“管理工具”-“事件查看器”，開事件查看器窗口。
方法三：在“運行”對話框中手工鍵入“%SystemRoot%/system32/eventvwr.msc /s”打開事件查看器窗口。
關閉IIS日志
當開啟記錄功能后，IIS會事無巨細地忠實記錄所有的web訪問記錄。這些記錄文件的內容是非常龐雜的，比如訪問時間、客戶端IP、從哪個鏈接訪問、?Cookies等，另外還包括?Method(方法), UserAgent(用戶代理)等。這些記錄不但占用大量的磁盤空間還大大地影響了web服務器的性能。有人做過評測，停止訪問記錄可以提升5%到8%的web性能。
啟用內容過期（客戶端緩存）
對于靜態文件啟用內容過期可以提高訪問性能。
1.???首先網站的目錄要劃分合理，圖片、CSS、JavaScript均放在單獨目錄下
2.???然后在IIS中選擇要緩存的目錄?> HTTP?響應標頭?>?設置常用標頭?>?設置"web內容過期"策略
如上圖webDemo站點，這樣，用戶瀏覽器將比較當前日期和截止日期，以便決定是顯示緩存頁還是從服務器請求更新的頁，由于圖片、CSS、JS通常變化較少，因此基本上都從本地緩存讀取，從而加快顯示速度。
參考：
????IIS7禁用單個靜態文件的客戶端緩存
服務器驗證緩存
IIS自動機制，會在訪問css、js等靜態文件時，返回給瀏覽器Last-Modified和Etag標記
參考：
????瀏覽器緩存之Last-Modified
????服務端的緩存驗證 Last-Modified和Etag
啟用Gzip壓縮
IIS?壓縮功能使用Gzip算法
gzip是HTTP的一種壓縮算法，HTTP壓縮是在Web服務器和瀏覽器間傳輸壓縮文本內容的方法。HTTP壓縮采用通用的壓縮算法如gzip等壓縮HTML、JavaScript或?CSS文件。壓縮的最大好處就是降低了網絡傳輸的數據量，從而提高客戶端瀏覽器的訪問速度。當然，同時也會增加一點點服務器的負擔。Gzip是比較常見的一種HTTP壓縮算法。
五、???IIS初始化（預加載），解決（被回收后）第一次訪問慢
參考：https://www.cnblogs.com/teamblog/p/6195078.html
設置之后，什么時候會自動初始化？
（比如初始化執行?Global.Application_Start?初始化函數）
會?-?應用程序池啟動、應用程序池回收、cmd->iisreset?（w3wp的PID會變）
不會?-?站點重啟（IIS站點右鍵?>?管理網站?>?重新啟動）、站點啟動
不會?- web.config更改引起的應用程序池回收
在IIS10版本上測試是上面行為。另外有人IIS8.5上使用也是同樣的行為，參考文章。
步驟一、安裝IIS應用程序初始化功能
步驟二、設置IIS上應用程序池啟動模式
常規?>?啟動模式
默認值：OnDemand（按需運行模式），另外值AlwaysRuning（始終運行模式）
優化設置：改為?AlwaysRunning（始終運行）
步驟三、設置站點預加載
在IIS上站點右鍵?>?管理網站?>?高級設置，把【預加載已啟用】設置為true。
步驟四、配置站點?web.config?，添加站點重啟后預加載請求的頁面
eg：地址：http://webdemo.com/home/about
這樣操作保存后，IIS會修改?web.config?添加如下內容
01 02 03 04 05 06 | <system.webServer> ????…… ????<applicationInitialization?doAppInitAfterRestart="true"> ????????<add?initializationPage="home/about" hostName="" /> ????</applicationInitialization> </system.webServer> |
如果只是初始化（比如只執行?Global.Application_Start?初始化函數），不需要訪問特定API進行額外資源的初始化，則不需要?<add initializationPage="**" />?子節點
常規?>?隊列長度
HTTP.sys?將針對應用程序池排隊的最大請求數。默認值1000，最大值65535。
如果設置太大則會消耗大量的系統資源 ，而設置太小會導致客戶端訪問時頻繁出現"503服務不可用"響應。
優化設置：可先改為?5000（設置為預期最多并發用戶數的1.5倍，官方參考
使用windows性能監控（性能監控：cmd->perfmon.msc），添加“HTTP Service Request Queues/CurrentQueueSize”指標，觀察某個應用程序池當前隊列中請求的個數。
啟用Web園（Web Garden），進程模型?>?最大工作進程數
在Web園中你可以配置此應用程序池所使用的最大工作進程數，默認為1，最大可以設置為4000000； 配置使用多個工作進程可以提高該應用程序池處理請求的性能，但是在設置為使用多個工作進程之前，請考慮以下兩點：?
1、每一個工作進程都會消耗系統資源和CPU占用率；太多的工作進程會導致系統資源和CPU利用率的急劇消耗；?
2、每一個工作進程都具有自己的狀態數據，如果Web應用程序依賴于工作進程保存狀態數據，那么可能不支持使用多個工作進程。?
這樣設置，增加了處理進程數，相當于集群，避免大量請求處于排隊狀態
參考：
IIS并發優化
文章介紹：使用windows性能監控：cmd->perfmon.msc。監控IIS應用運行情況，再根據需要進行iis參數設置
Web Service/Current Connections 監控某個應用程序池來指示當前該應用程序池的連接的數量。
ASP.NET Apps v4.0.30319/Requests Executing 監控所有的 ASP.Net 4.0 正在處理中的請求數量。
ASP.NET v4.0.30319/Requests Current 與上述類似用于監控 Asp.Net 4.0 正在處理中的請求數量。
HTTP Service Request Queues/CurrentQueueSize 用來監控某個應用程序池當前隊列中請求的個數。
調整支持并發請求的數量
默認支持并發請求數量為：5000
超出此并發數，會報異常
HTTP Error 503.2 - Service Unavailable
The serverRuntime@appConcurrentRequestLimit setting is being exceeded.
參考：
????IIS 并發請求設置如何設置？
站點最大并發連接數
右鍵站點?>?高級設置?>?限制?>?最大并發連接數
設置站點線程數：minWorkerThreads、maxWorkerThreads、maxIoThreads
（感謝園友?@?runliuv?提供的新姿勢）
maxWorkerThreads默認20，maxIoThreads默認20，minWorkerThreads默認1，minIoThreads默認1 ( eg：8核，默認分別就是160, 160, 8, 8 )
1、配置文件：C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
2、修改參數： <processModel autoConfig="false" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50"?minIoThreads="50" />
其中：minWorkerThreads = maxWorkerThreads / 2? ?;? ?minIoThreads =?maxIoThreads / 2?
參數具體值如何設置，還需要各自對站點進行壓力測試中調整
參考：
? ? ? ? 博客園"黑色30秒"事件
? ? ? ? ? ? ? ??排查“黑色30秒”問題-為什么請求會排隊
? ? ? ? ? ? ? ??[解決]從ASP.NET線程角度對“黑色30秒”問題的全新分析
IIS7.5優化--提高線程數來適應高并發
processModel 元素（ASP.NET 設置架構）
Improving ASP.NET Performance? ? （微軟文檔中給出了推薦值，如下圖）
為不同工作進程指定應用程序池（工作進程隔離模式）
一臺服務器上有非常多的Web站點。如何才能做到各個站點之間相互獨立，不因某些Web站點出現故障而影響其他站點呢?--為不同工作進程指定應用程序池是個很好的解決辦法。
進程模型?>?標識，使用ApplicationPoolIdentity虛擬賬戶
ApplicationPoolIdentity –?默認情況下，選擇“應用程序池標識”帳戶。啟動應用程序池時動態創建“應用程序池標識”帳戶，因此，此帳戶對于您的應用程序來說是最安全的。（這樣，每個應用程序池都有各自的賬戶，就避免了木馬上傳到其中一個池下站點，會對另一個池的文件夾有操作權限）
參考：
???IIS7.5中神秘的ApplicationPoolIdentity
啟用快速失敗保護
如果Web應用程序代碼編寫有問題，它可能會導致工作進程持續出現問題。默認情況下應用程序池配置為啟用快速失敗保護，當工作進程在配置的時間段（默認為5分鐘）內發生的失敗次數超過了配置的值（默認為5次），則禁用此應用程序池。
原文地址：https://www.cnblogs.com/heyuquan/p/deploy-iis-set-performance-guide.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總?http://www.csharpkit.com?
總結
以上是生活随笔為你收集整理的站点部署，IIS配置优化指南的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： .NET Core 3.0 webapi
- 下一篇： 张高兴的.NET Core IoT 入门