優化 IIS 10.0

Internet Information Services （IIS） 10.0 包含在 Windows Server 2022 中。 它使用類似於 IIS 8.5 和 IIS 7.0 的進程模型。 內核模式 Web 驅動程式 （http.sys） 接收和路由 HTTP 請求，並滿足來自其回應緩存的請求。 工作進程註冊 URL 子空間，http.sys 將請求路由到相應的進程（或應用程式池的進程集）。

HTTP.sys 負責連接管理和請求處理。 該請求可以從 HTTP.sys 緩存中提供，也可以傳遞給 worker 進程進行進一步處理。 可以配置多個工作進程，從而以更低的成本提供隔離。 有關請求處理工作原理的更多資訊，請參閱下圖：

HTTP.sys 包括回應緩存。 當請求與回應緩存中的條目匹配時，HTTP.sys 直接從內核模式發送緩存回應。 某些 Web 應用程式平臺（如 ASP.NET）提供了一些機制，使任何動態內容都能夠緩存在內核模式緩存中。 IIS 10.0 中的靜態文件處理程式會自動緩存 http.sys中經常請求的檔。

由於 Web 伺服器具有內核模式和使用者模式元件，因此必須優化這兩個元件以獲得最佳性能。 因此，針對特定工作負載優化 IIS 10.0 包括配置以下內容：

• HTTP.sys 和關聯的內核模式緩存

• 工作進程和使用者模式 IIS，包括應用程式池配置

• 影響性能的某些優化參數

以下部分討論如何配置 IIS 10.0 的內核模式和使用者模式方面。

核心模式設定

與性能相關的 HTTP.sys 設置分為兩大類：緩存管理和連接和請求管理。 所有註冊表設定都儲存在以下註冊表項下：

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters

便條 如果 HTTP 服務已在執行中，您必須重新啟動它，變更才會生效。

緩存管理設置

HTTP.sys 提供的一個好處是內核模式緩存。 如果響應位於內核模式緩存中，則可以完全從內核模式滿足 HTTP 請求，這大大降低了處理請求的 CPU 成本。 但是，IIS 10.0 的內核模式緩存基於物理記憶體，條目的成本是它佔用的記憶體。

緩存中的條目僅在使用時有用。 但是，無論是否正在使用該條目，該條目始終會佔用物理記憶體。 您必須通過考慮可用資源（CPU 和物理記憶體）和工作負載要求，評估緩存中專案的有用性（能夠從緩存中提供專案所節省的費用）及其成本（佔用的物理記憶體）。 HTTP.sys 嘗試在緩存中僅保留有用的、主動訪問的專案，但您可以通過針對特定工作負載調整 HTTP.sys 緩存來提高Web伺服器的性能。

以下是 HTTP.sys 內核模式緩存的一些有用設置：

• UriEnableCache 預設值：1

  非零值啟用內核模式回應和片段緩存。 對於大多數工作負載，緩存應保持啟用狀態。 如果您預計回應和片段緩存非常低，請考慮禁用緩存。

• UriMaxCacheMegabyteCount 預設值：0

  一個非零值，用於指定內核模式緩存可用的最大記憶體。 預設值 0 使系統能夠自動調整快取可用的記憶體存量。

  注意 指定的大小只設定最大上限，且系統可能不會讓快取增大到所設定的最大值。

  Â

• UriMaxUriBytes 預設值：262144 位元組 （256 KB）

  內核模式快取中條目的最大大小。 大於此大小的回應或片段不會被緩存。 如果您有足夠的記憶體，請考慮增加限制。 如果記憶體有限，並且大條目排擠了較小的條目，那麼降低限制可能會有所説明。

• UriScavenger期間 預設值：120 秒

  HTTP.sys 緩存由 Scave 程式定期掃描，並刪除在 Scavenger 掃描之間未訪問的條目。 將 scavenger period 設置為較高的值會減少 scavenger 掃描的次數。 但是，緩存記憶體使用量可能會增加，因為較舊、訪問頻率較低的條目可以保留在緩存中。 將時間段設置得太低會導致更頻繁的清道夫掃描，並可能導致過多的刷新和緩存改動。

請求和連接管理設置

在 Windows Server 2022 中，HTTP.sys 會自動管理連接。 以下註冊表設置不再使用：

• MaxConnections

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\MaxConnections
  

• IdleConnectionsHighMark

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsHighMark
  

• IdleConnectionsLowMark

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsLowMark
  

• IdleListTrimmerPeriod

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleListTrimmerPeriod
  

• RequestBufferLookasideDepth

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\RequestBufferLookasideDepth
  

• InternalRequestLookasideDepth

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\InternalRequestLookasideDepth
  

使用者模式設定

本節中的設置會影響 IIS 的 10.0 工作進程行為。 這些設定中的大多數都可以在以下 XML 設定檔中找到：

%SystemRoot%\system32\inetsrv\config\applicationHost.config

使用 Appcmd.exe、IIS 10.0 管理控制台、WebAdministration 或 IISAdministration PowerShell Cmdlet 來更改它們。 大多數設置都是自動檢測的，並且不需要重新啟動 IIS 10.0 工作進程或 Web 應用程式伺服器。 有關 applicationHost.config 檔的詳細資訊，請參閱 ApplicationHost.config簡介 。

NUMA 硬體的理想 CPU 設置

從 Windows Server 2016 開始，IIS 10.0 支援為其線程池線程自動分配理想 CPU，以增強 NUMA 硬體的性能和可伸縮性。 此功能預設啟用，可以通過以下註冊表項進行配置：

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\ThreadPoolUseIdealCpu

啟用此功能后，IIS 線程管理員會盡最大努力根據 IIS 線程池線程的當前負載在所有 NUMA 節點中的所有 CPU 之間均勻分佈 IIS 線程池線程。 通常，建議對 NUMA 硬體保持此預設設置不變。

注意 理想的 CPU 設定與 應用程式集區的 CPU 設定中引入的工作進程 NUMA 節點指派設定（如 numaNodeAssignment 和 numaNodeAffinityMode）不同。 理想的 CPU 設置會影響 IIS 分配其線程池線程的方式，而工作進程 NUMA 節點分配設置確定工作進程在哪個 NUMA 節點上啟動。

使用者模式快取行為設置

本節介紹影響 IIS 10.0 中緩存行為的設置。 使用者模式快取作為模組實現，該模組偵聽集成管道引發的全域緩存事件。 要完全禁用使用者模式緩存，請從 applicationHost.config的 system.webServer/globalModules 配置部分的已安裝模塊清單中刪除 FileCacheModule （cachfile.dll） 模組。

system.webServer/caching

壓縮行為設置

默認情況下，從 7.0 開始的 IIS 會壓縮靜態內容。 此外，在安裝 DynamicCompressionModule 時，預設情況下會啟用動態內容的壓縮。 壓縮會降低頻寬使用率，但會增加 CPU 使用率。 如果可能，壓縮內容將緩存在內核模式緩存中。 從 8.5 開始，IIS 允許獨立控制靜態和動態內容的壓縮。 靜態內容通常是指不變的內容，例如 GIF 或 HTM 檔。 動態內容通常由伺服器上的文稿或代碼（即 ASP.NET 頁）生成。 您可以將任何特定擴展的分類自定義為 static 或 dynamic。

要完全禁用壓縮，請從 applicationHost.config的 system.webServer/globalModules 部分的模組清單中刪除 StaticCompressionModule 和 DynamicCompressionModule 。

system.webServer/httpCompression

system.webServer/urlCompression

調整預設文件清單

預設 document 模組處理對目錄根目錄的 HTTP 請求，並將其轉換為對特定檔（如 Default.htm 或 Index.htm）的請求。 平均而言，Internet 上大約 25% 的請求通過預設文檔路徑。 這因各個網站而異。 當 HTTP 請求未指定檔案名時，預設文件模組會在檔案系統中搜索允許的預設文件清單中的每個名稱。 這可能會對性能產生負面影響，尤其是在訪問內容需要進行網路往返或接觸磁碟時。

您可以通過選擇性地禁用預設文件以及減少文件清單或對文件清單進行排序來避免開銷。 對於使用預設文件的網站，您應該將清單減少到僅使用的預設文檔類型。 此外，對清單進行排序，使其以最常訪問的預設文檔檔名開頭。

您可以通過在 applicationHost.config 中自定義location標記內的配置，或者通過在內容目錄中直接插入 web.config 檔，有選擇地設置特定URL上的預設文檔行為。 這允許使用混合方法，該方法僅在必要時啟用默認文檔，並將清單設置為每個URL的正確檔名。

要完全禁用預設文檔，請從 applicationHost.config的 system.webServer/globalModules 部分的模組清單中刪除 DefaultDocumentModule。

system.webServer/defaultDocument

中央二進位日誌記錄

當伺服器會話下有許多 URL 組時，為各個 URL 組創建數百個格式化日誌檔並將日誌數據寫入磁碟的過程可能會快速消耗寶貴的 CPU 和記憶體資源，從而產生性能和可伸縮性問題。 集中式二進位日誌記錄可最大限度地減少用於日誌記錄的系統資源量，同時為需要它的組織提供詳細的日誌數據。 解析二進位格式的日誌需要後處理工具。

您可以將 centralLogFileMode 屬性設定為 CentralBinary，並將 enabled 屬性設定為 True，以啟用中央二進位記錄。 考慮將中央日誌檔的位置從系統分區移動到專用日誌記錄驅動器上，以避免系統活動和日誌記錄活動之間發生爭用。

system.applicationHost/log

system.applicationHost/log/centralBinaryLogFile

應用程式和網站優化

以下設置與應用程式池和網站調整相關。

system.applicationHost/applicationPools/applicationPoolDefaults

system.applicationHost/sites/VirtualDirectoryDefault

管理 IIS 10.0 模組

IIS 10.0 已分解為多個用戶可擴展的模組，以支援模組化結構。 這種因式分解的成本很小。 對於每個模組，集成管道必須為與該模組相關的每個事件調用該模組。 無論模組是否必須執行任何工作，都會發生這種情況。 您可以通過刪除與特定網站無關的所有模組來節省 CPU 週期和記憶體。

針對簡單靜態檔優化的 Web 伺服器可能僅包含以下五個模組：UriCacheModule、HttpCacheModule、StaticFileModule、AnonymousAuthenticationModule 和 HttpLoggingModule。

要從 applicationHost.config中刪除模組，除了刪除 system.webServer/globalModules 中的模組聲明外，還要從 system.webServer/handlers 和 system.webServer/modules 部分中刪除對模組的所有引用。

傳統 ASP 設置

處理經典 ASP 請求的主要成本包括初始化腳本引擎、將請求的 ASP 腳本編譯為 ASP 範本以及在腳本引擎上執行範本。 雖然範本執行成本取決於請求的 ASP 腳本的複雜性，但 IIS 經典 ASP 模組可以在記憶體中緩存腳本引擎，並在記憶體和磁碟中緩存範本（僅當記憶體中範本緩存溢出時），以提高 CPU 密集型方案中的性能。

以下設置用於配置經典 ASP 範本快取和腳本引擎快取，它們不會影響 ASP.NET 設置。

system.webServer/asp/cache

system.webServer/asp/limits

system.webServer/asp/comPlus

ASP.NET 併發設置

ASP.NET 3.5

默認情況下，ASP.NET 限制請求併發性以減少伺服器上的穩態記憶體消耗。 高併發應用程式可能需要調整一些設置以提高整體性能。 您可以在 aspnet.config 檔案中變更此設定：

<system.web>
  <applicationPool maxConcurrentRequestsPerCPU="5000"/>
</system.web>

以下設置對於充分利用系統上的資源非常有用：

• maxConcurrentRequestPerCpu 預設值：5000

  此設置限制系統上併發執行的 ASP.NET 請求的最大數量。 默認值為 conservative 以減少 ASP.NET 應用程式的記憶體消耗。 請考慮在運行執行長時間同步 I/O作的應用程式的系統上增加此限制。 否則，當使用預設設置時，使用者可能會因排隊而遇到高延遲，或者由於在高負載下超出佇列限制而導致請求失敗。

ASP.NET 4.6

除了 maxConcurrentRequestPerCpu 設置外，ASP.NET 4.7 還提供了一些設置，以提高嚴重依賴異步作的應用程式的性能。 可以在 aspnet.config 檔中更改該設置。

<system.web>
  <applicationPool percentCpuLimit="90" percentCpuLimitMinActiveRequestPerCpu="100"/>
</system.web>

• %Cpu限制 預設值：90 當此類場景上施加巨大負載（超出硬體功能）時，非同步請求會發生一些可擴展性問題。 該問題是由於異步方案中分配的性質造成的。 在這些情況下，分配將在異步作啟動時發生，並在異步作完成時被消耗。 到那時，物件很可能已經被 GC 放在第 1 代或第 2 代。 發生這種情況時，增加負載將顯示每秒請求增加 （rps），直到某個點。 一旦我們通過了那個點，花在 GC 上的時間就會開始成為一個問題，rps 就會開始下降，從而產生負面的擴展效應。 要解決此問題，當 cpu 使用率超過 percentCpuLimit 設置時，請求將發送到 ASP.NET 本機佇列。
• percentCpuLimitMinActiveRequestPerCpu 預設值：100 CPU 節流 （percentCpuLimit 設定） 不是基於請求數量，而是基於請求的成本。 因此，可能只有少數 CPU 密集型請求會導致本機佇列中出現備份，除了傳入請求之外，無法清空它。 為了解決這個問題，可以使用percentCpuLimitMinActiveRequestPerCpu來確保在限制開始之前提供最少數量的請求。

工作進程和回收選項

您可以配置用於回收 IIS 工作進程的選項，並為緊急情況或事件提供實用的解決方案，而無需干預或重置服務或計算機。 此類情況和事件包括記憶體洩漏、記憶體負載增加或工作進程無回應或空閒。 在正常情況下，可能不需要回收選項，可以關閉回收，或者可以將系統配置為非常不頻繁地回收。

您可以將屬性新增至 recycling/periodicRestart 元素，以啟用特定應用程式的處理程序回收。 回收事件可以由多個事件觸發，包括記憶體使用方式、固定數量的請求和固定的時間段。 當工作進程被回收時，排隊和正在執行的請求將被耗盡，並同時啟動新進程來為新請求提供服務。 recycling/periodicRestart 元素是針對每個應用程式的，這意味著下表中的每個屬性都會基於每個應用程式進行分割。

system.applicationHost/applicationPools/ApplicationPoolDefaults/recycling/periodicRestart

動態工作進程分頁調優

從 Windows Server 2012 R2 開始，IIS 提供了將工作進程配置為在空閒一段時間後掛起的選項（除了自 IIS 7 以來就存在的終止選項）。

idle worker process page-out 和 idle worker process termination 功能的主要目的是節省伺服器上的記憶體利用率，因為即使網站只是坐在那裡偵聽，也會消耗大量記憶體。 根據網站上使用的技術（靜態內容 vs ASP.NET 與其他框架），使用的記憶體可以從大約 10 MB 到數百 MB 不等，這意味著如果您的伺服器配置了許多網站，則找出最有效的網站設置可以顯著提高活動網站和暫停網站的性能。

在討論細節之前，我們必須記住，如果沒有記憶體限制，那麼最好簡單地將網站設置為永不暫停或終止。 畢竟，如果 worker 進程是機器上唯一的進程，那麼終止它幾乎沒有價值。

另一個需要考慮的因素是，如果網站確實使用了大量記憶體，則暫停進程本身會造成損失，因為計算機必須將工作進程使用的數據寫入磁碟。 如果 worker 進程正在使用大量記憶體，則暫停它可能比必須等待它啟動備份的成本更高。

為了充分利用工作進程暫停功能，您需要查看每個應用程式池中的網站，並決定哪些應該暫停，哪些應該終止，哪些應該無限期處於活動狀態。 對於每個作和每個網站，您需要找出理想的超時時間。

理想情況下，您將配置為暫停或終止的網站是那些每天都有訪問者的網站，但不足以保證它始終保持活動狀態。 這些網站通常是每天有大約 20 名獨立訪問者或更少的網站。 您可以使用網站的紀錄檔分析流量模式並計算平均每日流量。

請記住，一旦特定使用者連接到該網站，他們通常會在該網站上停留至少一段時間，併發出額外的請求，因此僅計算每日請求可能無法準確反映真實的流量模式。 為了獲得更準確的讀數，您還可以使用 Microsoft Excel 等工具來計算請求之間的平均時間。 例如：

不過，困難的部分是弄清楚要應用什麼設置才有意義。 在我們的例子中，該網站收到了來自使用者的大量請求，上表顯示 4 小時內總共發生了 4 個唯一會話。 使用應用程式池的工作進程暫停的預設設置，網站將在預設超時 20 分鐘後終止，這意味著這些使用者中的每一個都將經歷網站啟動週期。 這使它成為工作進程暫停的理想候選項，因為在大多數情況下，網站處於空閒狀態，因此暫停它可以節省資源，並允許用戶幾乎立即訪問網站。

關於這一點，最後也是非常重要的一點是，磁碟性能對於此功能至關重要。 由於暫停和喚醒過程涉及向硬碟驅動器寫入和讀取大量數據，因此我們強烈建議使用快速磁碟。 固態硬碟 （SSD） 是理想的選擇，強烈推薦使用，您應該確保 Windows 頁面檔存儲在其上（如果作系統本身未安裝在 SSD 上，請配置作系統以將頁面檔移動到其中）。

無論您是否使用 SSD，我們還建議修復頁面檔的大小，以適應將頁面輸出數據寫入其中而無需調整檔大小。 當作系統需要在頁面檔中存儲數據時，可能會發生頁面檔大小調整，因為預設情況下，Windows 配置為根據需要自動調整其大小。 通過將大小設置為固定大小，可以防止調整大小並大幅提高性能。

要配置預先固定的頁面檔大小，您需要計算其理想大小，這取決於您將暫停的網站數量以及它們消耗的內存量。 如果活動工作進程的平均大小為 200 MB，並且伺服器上有 500 個網站將掛起，則頁面檔應至少比頁面檔的基本大小高出 （200 * 500） MB（在本例中為 base + 100 GB）。

傳輸層安全性調優參數

使用傳輸層安全性 （TLS） 會帶來額外的 CPU 成本。 TLS 最昂貴的組成部分是建立會話建立的成本，因為它涉及完全握手。 重新連接、加密和解密也會增加成本。 為了獲得更好的 TLS 性能，請執行以下作：

• 為 TLS 會話啟用 HTTP keep-alive。 這消除了會話建立成本。

• 在適當的時候重用會話，尤其是對於非保持活動流量。

• 有選擇地僅將加密應用於需要加密的頁面或網站部分，而不是整個網站。

Internet 伺服器應用程式程式程式編程介面 （ISAPI）

ISAPI 應用程式不需要特殊的優化參數。 如果您編寫私有 ISAPI 擴展，請確保它是為性能和資源使用而編寫的。

託管代碼優化準則

IIS 10.0 中的集成管道模型可實現高度的靈活性和可擴充性。 在本機代碼或託管代碼中實現的自定義模組可以插入到管道中，也可以替換現有模組。 儘管此擴展性模型提供了便利和簡單性，但在插入掛接到全域事件的新託管模組之前，您應該小心。 添加全域託管模組意味著所有請求（包括靜態檔請求）都必須接觸託管代碼。 自定義模組容易受到垃圾回收等事件的影響。 此外，由於在本機代碼和託管代碼之間封送數據，自定義模組會顯著增加 CPU 成本。 如果可能，您應該將 managedModule 的 preCondition 設置為 managedHandler。

要獲得更好的冷啟動性能，請確保預編譯 ASP.NET 網站或利用 IIS 應用程式初始化功能來預熱應用程式。

如果不需要工作階段狀態，請確保為每個頁面關閉它。

如果有很多 I/O 綁定作，請嘗試使用相關 API 的異步版本，這將為您提供更好的可擴充性。

此外，正確使用輸出緩存也將提高您網站的性能。

當您在隔離模式下運行多個包含 ASP.NET 腳本的主機時（每個網站一個應用程式池），請監控記憶體使用方式。 確保伺服器具有足夠的 RAM 來儲存預期數量的併發運行的應用程式池。 考慮使用多個應用程式域，而不是多個隔離的進程。

影響 IIS 性能的其他問題

以下問題可能會影響 IIS 性能：

• 安裝無法識別緩存的篩檢程式

  安裝非 HTTP 快取感知的篩選器會導致 IIS 完全禁用緩存，從而導致性能不佳。 在 IIS 6.0 之前編寫的 ISAPI 篩選器可能會導致此行為。

• 通用閘道介面 （CGI） 請求

  出於性能原因，對於 IIS，不建議使用 CGI 應用程式來處理請求。 頻繁創建和刪除 CGI 進程涉及大量開銷。 更好的替代方案包括使用 FastCGI、ISAPI 應用程式腳本和 ASP 或 ASP.NET 腳本。 隔離可用於這些選項中的每一個。

其他參考資料

• 網頁伺服器效能微調
• HTTP 1.1/2 調優