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 初始化函數)

 

1)會 - 應用程序池啟動、應用程序池回收、cmd->iisreset (w3wp的PID會變)

 

2)不會 - 站點重啟(IIS站點右鍵 > 管理網站 > 重新啟動)、站點啟動

 

3)不會 - web.config更改引起的應用程序池回收

 

IIS10版本上測試是上面行為。另外有人IIS8.5上使用也是同樣的行為,參考文章。

 

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

 

步驟二、設置IIS上應用程序池啟動模式

 

常規 > 啟動模式

 

默認值:OnDemand(按需運行模式),另外值AlwaysRuning(始終運行模式)

 

優化設置:改為 AlwaysRunning(始終運行)

 

步驟三、設置站點預加載

 

IIS上站點右鍵 > 管理網站 > 高級設置,把【預加載已啟用】設置為true。

 

 

 

 

步驟四、配置站點 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="**" /> 子節點

 

六、並發性

 

常規 > 隊列長度

 

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; 配置使用多個工作進程可以提高該應用程序池處理請求的性能,但是在設置為使用多個工作進程之前,請考慮以下兩點: 

 

1、每一個工作進程都會消耗系統資源和CPU占用率;太多的工作進程會導致系統資源和CPU利用率的急劇消耗; 

 

2、每一個工作進程都具有自己的狀態數據,如果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

 

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

 

2、修改參數: <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    (微軟文檔中給出了推薦值,如下圖)

 

 

 

 

七、安全性

 

為不同工作進程指定應用程序池(工作進程隔離模式)

 

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

 

進程模型 > 標識,使用ApplicationPoolIdentity虛擬賬戶

 

ApplicationPoolIdentity – 默認情況下,選擇“應用程序池標識”帳戶。啟動應用程序池時動態創建“應用程序池標識”帳戶,因此,此帳戶對於您的應用程序來說是最安全的。(這樣,每個應用程序池都有各自的賬戶,就避免了木馬上傳到其中一個池下站點,會對另一個池的文件夾有操作權限)

 

參考:IIS7.5中神秘的ApplicationPoolIdentity

 

啟用快速失敗保護

 

 

 

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


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM