站點部署，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. 1.   限制：10000 （以百分比*1000計算，10000則表示10%）

2. 2.   限制操作：1、noaction 無操作 2、KillW3wp 刪除行程 併在限制時間內重新開啟新行程

3. 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. 1.   首先網站的目錄要劃分合理，圖片、CSS、JavaScript均放在單獨目錄下

2. 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進行額外資源的初始化，則不需要  子節點

常規 > 佇列長度

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、修改引數：

其中：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次），則禁用此應用程式池。

分享