站點部署，IIS配置優化指南
目錄
通常把站點發布到IIS上執行正常後，很少會去考慮IIS提供的各種引數，如何配置才是最適合當前站點執行需要的？這篇文章，從基本設定、回收機制、效能、併發、安全性等IIS設定講解應當如何優化。
先來“IIS應用程式池”優化後的引數配置截圖：
圖中一些數值限制引數，可以藉助一些工具（如：windows效能監控）觀察站點執行的指標進行設定，具體後面會介紹到
下面來分別解說下這些引數為什麼要這樣設定（注：文章中的引數，不是按照應用程式池的設定從上到下排列的，而是按照優化的功能點排列）
一、設定應用程式池預設設定
按如下圖進行預設引數模板設定，設定後，新建的應用程式池就使用這個預設引數模板。
二、常規設定
IIS版本號檢視
在iis管理器中->幫助->關於Internet資訊服務，如下圖，版本是IIS10.
常規>啟動32位應用程式
預設值：False
優化設定：按需設定。如果確認站點依賴一些32位的元件，需將此設定為true。
建議：為32bit應用程式的網站單獨建立一個應用程式池
參考：
常規>託管管道模式
IIS7應用程式池新增的經典模式和整合模式
經典模式：是為了保留和IIS6一樣的處理方式，以前開發的程式碼，可以方便的移植到IIS7上。
整合模式：將ASP.NET請求管道與IIS核心管道組合在一起，這種模式與作業系統結合更緊密，能夠提供更好的效能，能夠實現配置和治理的模組化，而且增加了使用託管程式碼模組擴充套件IIS時的靈活性。
優化設定： 改為Integrated（整合模式）
參考：
三、優化回收策略
回收>固定時間間隔（分鐘）
一個時間段，超過該時間段，應用程式池將回收。值為0，則應用程式池不會按固定間隔回收
預設值：1740分鐘，29小時
優化設定：改為0。因為無法避免在高峰期發生回收。同時設定“回收>特定時間”
回收>特定時間
應用程式池進行回收的一組特定的本地時間（24小時制）
優化設定：固定在低峰期時回收。eg：設定為04:00、15:30等
另外，也可以使用windows計劃任務實現iis站點每週六晚定時回收
程序模型>閒置超時（分鐘）
一個時間段，設定工作程序允許保持閒置狀態的最大時間間隔，超過該時間就會自動關閉。
優化設定：改為0，避免記憶體資訊頻繁被回收清空。同時設定“回收>特定時間”
程序模型>空閒超時操作
預設是“Terminate”（另一個選項是“Suspend”）。
Terminate表示一旦超時就終止服務，並回收工作程序的緩衝區的記憶體；
Suspend則懸停等待，暫不回收緩衝區記憶體。
另外：
CPU超限佔用安全方案設定
CPU限制並不是用於控制每個程序的CPU利用率，而是一種處理髮生CPU超限的工作程序的安全方案，這樣可以避免工作程序佔用CPU過久。
參考：
iis中對cpu限制的操作：
- 限制：10000（以百分比*1000計算，10000則表示10%）
- 限制操作：1、noaction無操作2、KillW3wp刪除程序 並在限制時間內重新開啟新程序
- 限制間隔（分鐘）：設定時間限制，多久時間內重啟和檢測
記憶體超限回收機制
根據實際執行情況設定"回收>虛擬記憶體限制"和"回收>專用記憶體限制"，預設為禁用狀態，一般不用為此專門設定。
開啟|關閉時間限制
根據實際執行情況設定，預設90秒。如上圖，我都設定為了120秒
程序模型>關閉時間限制（秒）：為工作程序指定的，完成處理請求並關閉的時間段。如果工作程序超過關閉時間限制，將被終止。
程序模型>啟動時間限制（秒）：為工作程序指定的，啟動並進行初始化的時間段。如果工作程序初始化時間超過啟動時間限制，將被終止。
回收>禁用重疊回收
預設值false。應用程式池使用重疊回收方式。在這種方式下，當應用程式池要關閉某個工作程序時，會先建立一個工作程序，直到新的工作程序成功建立後才關閉舊的工作程序；
設定為true，則先關閉舊的工作程序，然後再建立新的工作程序。如果Web應用程式不支援多例項執行，那麼你必須配置應用程式池禁止使用重疊回收方式。
回收>生成回收事件條目
IIS事件檢視器
方法一：點選“開始→執行”，輸入eventvwr，點選“確定”，就可以開啟事件檢視器。
方法二：單擊“開始”-“設定”-“控制面板”-“管理工具”-“事件檢視器”，開事件檢視器視窗。
方法三：在“執行”對話方塊中手工鍵入“%SystemRoot%/system32/eventvwr.msc /s”開啟事件檢視器視窗。
四、效能
關閉IIS日誌
當開啟記錄功能後，IIS會事無鉅細地忠實記錄所有的web訪問記錄。這些記錄檔案的內容是非常龐雜的，比如訪問時間、客戶端IP、從哪個連結訪問、Cookies等，另外還包括Method(方法), UserAgent(使用者代理)等。這些記錄不但佔用大量的磁碟空間還大大地影響了web伺服器的效能。有人做過評測，停止訪問記錄可以提升5%到8%的web效能。
啟用內容過期（客戶端快取）
對於靜態檔案啟用內容過期可以提高訪問效能。
- 首先網站的目錄要劃分合理，圖片、CSS、JavaScript均放在單獨目錄下
- 然後在IIS中選擇要快取的目錄> HTTP響應標頭>設定常用標頭>設定"web內容過期"策略
如上圖webDemo站點，這樣，使用者瀏覽器將比較當前日期和截止日期，以便決定是顯示快取頁還是從伺服器請求更新的頁，由於圖片、CSS、JS通常變化較少，因此基本上都從本地快取讀取，從而加快顯示速度。
參考：
伺服器驗證快取
IIS自動機制，會在訪問css、js等靜態檔案時，返回給瀏覽器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初始化函式）
1)會-應用程式池啟動、應用程式池回收、cmd->iisreset（w3wp的PID會變）
2)不會-站點重啟（IIS站點右鍵>管理網站>重新啟動）、站點啟動
3)不會- 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>
……
<applicationInitializationdoAppInitAfterRestart="true">
<addinitializationPage="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應用程式依賴於工作程序儲存狀態資料，那麼可能不支援使用多個工作程序。
這樣設定，增加了處理程序數，相當於叢集，避免大量請求處於排隊狀態
參考：
文章介紹：使用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.
參考：
站點最大併發連線數
右鍵站點>高階設定>限制>最大併發連線數
設定站點執行緒數：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秒"事件
[解決]從ASP.NET執行緒角度對“黑色30秒”問題的全新分析
Improving ASP.NET Performance （微軟文件中給出了推薦值，如下圖）
七、安全性
為不同工作程序指定應用程式池（工作程序隔離模式）
一臺伺服器上有非常多的Web站點。如何才能做到各個站點之間相互獨立，不因某些Web站點出現故障而影響其他站點呢?--為不同工作程序指定應用程式池是個很好的解決辦法。
程序模型>標識，使用ApplicationPoolIdentity虛擬賬戶
ApplicationPoolIdentity –預設情況下，選擇“應用程式池標識”帳戶。啟動應用程式池時動態建立“應用程式池標識”帳戶，因此，此帳戶對於您的應用程式來說是最安全的。（這樣，每個應用程式池都有各自的賬戶，就避免了木馬上傳到其中一個池下站點，會對另一個池的資料夾有操作許可權）
參考：
IIS7.5中神祕的ApplicationPoolIdentity
啟用快速失敗保護
如果Web應用程式程式碼編寫有問題，它可能會導致工作程序持續出現問題。預設情況下應用程式池配置為啟用快速失敗保護，當工作程序在配置的時間段（預設為5分鐘）內發生的失敗次數超過了配置的值（預設為5次），則禁用此應用程式池。
八、多伺服器IIS集中化管理web
Microsoft IIS Administration微軟提供，管理IIS配置的REST API和集中化IIS管理WEB UI。
l支援絕大部分IIS配置項管理
l支援管理遠端IIS，實現集中化IIS配置管理。
l支援REST API，方便整合到自研系統。
l支援IIS配置訪問安全性設定
詳細檢視：多伺服器IIS集中化管理web和程式設計訪問IIS
其他閱讀：
===========================================================
轉自：http://Www.CnBlogs.Com/WebEnh/| 本部落格Android APP 下載 |
| 支援我們就給我們點打賞 |
| 支付寶打賞 支付寶掃一掃二維碼 |
| 微信打賞 微信掃一掃二維碼 |
如果想下次快速找到我，記得點下面的關注哦！