目錄

一、       設定應用程式池預設設定... 2

二、       常規設定... 3

三、       優化回收策略... 5

四、       效能... 8

五、       IIS初始化（預載入），解決（被回收後）第一次訪問慢... 9

六、       併發性... 11

七、       安全性... 12

通常把站點發布到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 初始化函式）

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 新增如下內容

<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園中你可以配置此應用程式池所使用的最大工作程序數，預設為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 併發請求設定如何設定？

站點最大併發連線數

右鍵站點 > 高階設定 > 限制 > 最大併發連線數

七、  安全性

為不同工作程序指定應用程式池（工作程序隔離模式）

一臺伺服器上有非常多的Web站點。如何才能做到各個站點之間相互獨立，不因某些Web站點出現故障而影響其他站點呢?--為不同工作程序指定應用程式池是個很好的解決辦法。

程序模型 > 標識，使用ApplicationPoolIdentity虛擬賬戶

ApplicationPoolIdentity – 預設情況下，選擇“應用程式池標識”帳戶。啟動應用程式池時動態建立“應用程式池標識”帳戶，因此，此帳戶對於您的應用程式來說是最安全的。（這樣，每個應用程式池都有各自的賬戶，就避免了木馬上傳到其中一個池下站點，會對另一個池的資料夾有操作許可權）

參考：

   IIS7.5中神祕的ApplicationPoolIdentity

啟用快速失敗保護

如果Web應用程式程式碼編寫有問題，它可能會導致工作程序持續出現問題。預設情況下應用程式池配置為啟用快速失敗保護，當工作程序在配置的時間段（預設為5分鐘）內發生的失敗次數超過了配置的值（預設為5次），則禁用此應用程式池。

===========================================================

  over，謝謝查閱，覺得文章對你有收穫，請多幫推薦。歡迎提供更好的資料資訊。