歡迎光臨
每天分享高質量文章

站點部署,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小時

優化設置:改為。因為無法避免在高峰期發生回收。同時設置回收 > 特定時間

回收 > 特定時間

應用程式池進行回收的一組特定的本地時間(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.   限制操作:1noaction 無操作 2KillW3wp 刪除行程 併在限制時間內重新開啟新行程

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

  2. 2.   然後在IIS中選擇要快取的目錄 > HTTP 響應標頭 > 設置常用標頭 > 設置“web內容過期策略

如上圖webDemo站點,這樣,用戶瀏覽器將比較當前日期和截止日期,以便決定是顯示快取頁還是從服務器請求更新的頁,由於圖片、CSSJS通常變化較少,因此基本上都從本地快取讀取,從而加快顯示速度。

參考:

    IIS7禁用單個靜態檔案的客戶端快取

服務器驗證快取

IIS自動機制,會在訪問cssjs等靜態檔案時,傳回給瀏覽器Last-ModifiedEtag標記

參考:

    瀏覽器快取之Last-Modified

    服務端的快取驗證 Last-Modified和Etag

啟用Gzip壓縮

IIS 壓縮功能使用Gzip演算法

gzipHTTP的一種壓縮演算法,HTTP壓縮是在Web服務器和瀏覽器間傳輸壓縮文本內容的方法。HTTP壓縮採用通用的壓縮演算法如gzip等壓縮HTMLJavaScript CSS檔案。壓縮的最大好處就是降低了網絡傳輸的資料量,從而提高客戶端瀏覽器的訪問速度。當然,同時也會增加一點點服務器的負擔。Gzip是比較常見的一種HTTP壓縮演算法。

五、   IIS初始化(預加載),解決(被回收後)第一次訪問慢

參考:https://www.cnblogs.com/teamblog/p/6195078.html

設置之後,什麼時候會自動初始化?

(比如初始化執行 Global.Application_Start 初始化函式)

  •  – 應用程式池啟動、應用程式池回收、cmd->iisreset w3wpPID會變)

  • 不會 – 站點重啟(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 [email protected] 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次),則禁用此應用程式池。

已同步到看一看
赞(0)

分享創造快樂