IIS基本設置、回收機制、性能、併發、安全性

一般把站點發布到IIS上運行正常後，不多會去考慮IIS提供的各類參數，如何配置纔是最適合當前站點運行須要的？這篇文章，從基本設置、回收機制、性能、併發、安全性等IIS設置講解應當如何優化。

 

先來「IIS應用程序池」優化後的參數配置截圖：

 

圖中一些數值限制參數，能夠藉助一些工具（如：windows性能監控）觀察站點運行的指標進行設置，具體後面會介紹到

 

 

下面來分別解說下這些參數爲何要這樣設置（注：文章中的參數，不是按照應用程序池的設置從上到下排列的，而是按照優化的功能點排列）

 

1、設置應用程序池默認設置

 

按以下圖進行默認參數模板設置，設置後，新建的應用程序池就使用這個默認參數模板。

 

2、常規設置

 

IIS版本號查看

 

在iis管理器中->幫助->關於Internet信息服務，以下圖，版本是IIS10.

 

 

常規 > 啓動32位應用程序

 

默認值：False

 

優化設置：按需設置。若是確認站點依賴一些32位的組件，需將此設置爲true。

 

建議：爲 32bit 應用程序的網站單首創建一個應用程序池

 

參考：64位系統上iis運行32位的網站程序

 

常規 > 託管管道模式

 

IIS7 應用程序池新增的經典模式和集成模式

 

經典模式：是爲了保留和IIS6同樣的處理方式，之前開發的代碼，能夠方便的移植到IIS7上。

 

集成模式：將ASP.NET請求管道與IIS核心管道組合在一塊兒，這種模式與操做系統結合更緊密，可以提供更好的性能，可以實現配置和治理的模塊化，並且增長了使用託管代碼模塊擴展IIS時的靈活性。

 

優化設置： 改成 Integrated（集成模式）

 

參考：對IIS7經典模式和集成模式的理解

 

3、 優化回收策略

 

回收 > 固定時間間隔（分鐘）

 

一個時間段，超過該時間段，應用程序池將回收。值爲 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.限制操做：一、noaction 無操做 二、KillW3wp 刪除進程 並在限制時間內從新開啓新進程

 

3.限制間隔（分鐘）：設置時間限制，多久時間內重啓和檢測

 

內存超限回收機制

 

根據實際運行狀況設定 "回收 > 虛擬內存限制" 和 "回收 > 專用內存限制"，默認爲禁用狀態，通常不用爲此專門設定。

 

開啓|關閉時間限制

 

根據實際運行狀況設定，默認90秒。如上圖，我都設置爲了120秒

 

進程模型 > 關閉時間限制（秒）：爲工做進程指定的，完成處理請求並關閉的時間段。若是工做進程超過關閉時間限制，將被終止。

 

進程模型 > 啓動時間限制（秒）：爲工做進程指定的，啓動並進行初始化的時間段。若是工做進程初始化時間超過啓動時間限制，將被終止。

 

回收 > 禁用重疊回收

 

默認值 false。應用程序池使用重疊回收方式。在這種方式下，當應用程序池要關閉某個工做進程時，會先建立一個工做進程，直到新的工做進程成功建立後才關閉舊的工做進程； 

 

設置爲 true，則先關閉舊的工做進程，而後再建立新的工做進程。 若是Web 應用程序不支持多實例運行，那麼你必須配置應用程序池禁止使用重疊回收方式。

 

回收 > 生成回收事件條目

 

IIS事件查看器

 

方法一：點擊「開始→運行」，輸入eventvwr，點擊「肯定」，就能夠打開事件查看器。

 

方法二：單擊「開始」-「設置」-「控制面板」-「管理工具」-「事件查看器」，開事件查看器窗口。

 

方法三：在「運行」對話框中手工鍵入「%SystemRoot%/system32/eventvwr.msc /s」打開事件查看器窗口。

 

4、性能

 

關閉IIS日誌

 

當開啓記錄功能後，IIS會事無鉅細地忠實記錄全部的web訪問記錄。這些記錄文件的內容是很是龐雜的，好比訪問時間、客戶端IP、從哪一個連接訪問、 Cookies等，另外還包括 Method(方法), UserAgent(用戶代理)等。這些記錄不但佔用大量的磁盤空間還大大地影響了web服務器的性能。有人作過評測，中止訪問記錄能夠提高5%到8%的web性能。

 

啓用內容過時（客戶端緩存）

 

對於靜態文件啓用內容過時能夠提升訪問性能。

 

一、首先網站的目錄要劃分合理，圖片、CSS、JavaScript均放在單獨目錄下

 

二、而後在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壓縮算法。

 

5、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上使用也是一樣的行爲，參考文章。

 

步驟1、安裝IIS應用程序初始化功能

 

步驟2、設置IIS上應用程序池啓動模式

 

常規 > 啓動模式

 

默認值：OnDemand（按需運行模式），另外值AlwaysRuning（始終運行模式）

 

優化設置：改成 AlwaysRunning（始終運行）

 

步驟3、設置站點預加載

 

在IIS上站點右鍵 > 管理網站 > 高級設置，把【預加載已啓用】設置爲true。

 

 

 

 

步驟4、配置站點 web.config ，添加站點重啓後預加載請求的頁面

地址：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="**" /> 子節點

 

6、併發性

 

常規 > 隊列長度

 

HTTP.sys 將針對應用程序池排隊的最大請求數。默認值1000，最大值65535。

 

若是設置太大則會消耗大量的系統資源 ，而設置過小會致使客戶端訪問時頻繁出現"503服務不可用"響應。

 

優化設置：可先改成 5000（設置爲預期最多併發用戶數的1.5倍，官方參考:https://docs.microsoft.com/zh-cn/previous-versions/office/communications-server/dd441171(v=office.13)

 

使用windows性能監控（性能監控：cmd->perfmon.msc），添加「HTTP Service Request Queues/CurrentQueueSize」指標，觀察某個應用程序池當前隊列中請求的個數。

 

啓用Web園（Web Garden），進程模型 > 最大工做進程數

 

在Web園中你能夠配置此應用程序池所使用的最大工做進程數，默認爲1，最大能夠設置爲4000000； 配置使用多個工做進程能夠提升該應用程序池處理請求的性能，可是在設置爲使用多個工做進程以前，請考慮如下兩點： 

 

一、每個工做進程都會消耗系統資源和CPU佔用率；太多的工做進程會致使系統資源和CPU利用率的急劇消耗； 

 

二、每個工做進程都具備本身的狀態數據，若是Web應用程序依賴於工做進程保存狀態數據，那麼可能不支持使用多個工做進程。 

 

這樣設置，增長了處理進程數，至關於集羣，避免大量請求處於排隊狀態

 

參考：IIS併發優化 (https://www.jianshu.com/p/5de10f1a994e)

 

文章介紹：使用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 提供的新姿式）

 

minWorkerThreads默認1，maxWorkerThreads默認20，maxIoThreads默認20

 

一、配置文件：C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config

 

二、修改參數： <processModel autoConfig="false" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" />

 

其中：minWorkerThreads = maxWorkerThreads / 2

 

參數具體值如何設置，還須要各自對站點進行壓力測試中調整

 

參考：

 

IIS7.5優化--提升線程數來適應高併發https://www.cnblogs.com/lpyicq/p/7852298.html

 

processModel 元素（ASP.NET 設置架構）

 

Improving ASP.NET Performance    （微軟文檔中給出了推薦值，以下圖）

 

 

 

 

7、安全性

 

爲不一樣工做進程指定應用程序池（工做進程隔離模式）

 

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

 

進程模型 > 標識，使用ApplicationPoolIdentity虛擬帳戶

 

ApplicationPoolIdentity – 默認狀況下，選擇「應用程序池標識」賬戶。啓動應用程序池時動態建立「應用程序池標識」賬戶，所以，此賬戶對於您的應用程序來講是最安全的。（這樣，每一個應用程序池都有各自的帳戶，就避免了木立刻傳到其中一個池下站點，會對另外一個池的文件夾有操做權限）

 

參考：IIS7.5中神祕的ApplicationPoolIdentity

 

啓用快速失敗保護

 

 

 

若是Web應用程序代碼編寫有問題，它可能會致使工做進程持續出現問題。默認狀況下應用程序池配置爲啓用快速失敗保護，當工做進程在配置的時間段（默認爲5分鐘）內發生的失敗次數超過了配置的值（默認爲5次），則禁用此應用程序池。