引數說明

1.常規

Classic模式：指的是與IIS 6或者之前版本保持相容的一種模式，一個典型問題就是，在處理ASP.NET這種動態網站的時候，它是通過一個所謂的ISAPI程式，作為外掛的方式來工作的。針對不同的動態應用程式（例如ASP,PHP等），會需要不同的ISAPI。
Integrated模式

2.CUP

3.回收

4.程序孤立

5.程序模型

標識詳解：

• 本地系統： 具有高許可權的受信任帳戶，還具有對網路資源的訪問許可權。
• 網路服務： 用於執行標準的最小特權服務的受限或有限服務帳戶。 此帳戶具有比本地系統帳戶更少的許可權。 此帳戶可以訪問網路資源。
• 本地服務： 受限制或有限的服務帳戶，與網路服務類似，旨在執行標準的最小特權服務。 此帳戶無權訪問網路資源。
• ApplicationPoolIdentity： 當建立新的應用程式池時，IIS 將建立一個虛擬帳戶，該帳戶具有新應用程式池的名稱，並在此帳戶下執行應用程式池工作程序。 這也是一個具有最小特權的帳戶。
• 自定義帳戶： 除了這些內建帳戶之外，還可以通過指定使用者名稱和密碼來使用自定義帳戶。

6.快速故障防護

應用程式池優化配置

1.常規設定

1. 佇列長度： 預設值1000，將原來的佇列長度改為 65535。
2. 啟動32位應用程式：預設值False，改為True。
3. 託管管道模式：Integrated 或 Classsic。
   

2.回收設定

1. 禁用重疊回收。
2. 設定為特定時間=true，每天晚上04：00分回收。
   

3.程序設定

1. 標識設定,根據實際情況選擇，可參照上面的使用者定義。
2. 設定閒置超時，程序啟動後，規定時間（根據實際情況設定）內未分配任務則回收此資源。
3. 設定工作程序數。
   

HTTP.sys優化配置

HTTP.sys 負責連線管理和請求處理。 可以從 HTTP.sys 快取提供請求，或將請求傳遞到工作程序進行進一步處理。 可以配置多個工作程序，從而以降低的成本提供隔離。 有關請求處理的工作原理的詳細資訊，請參閱下圖：

HTTP.sys 包括響應快取。 當請求與響應快取中的條目相匹配時，HTTP.sys 會直接從核心模式傳送快取響應。 某些 web 應用程式平臺（如 ASP.NET）提供了一些機制，可以在核心模式快取中快取任何動態內容。 IIS 10.0 中的靜態檔案處理程式在 http.sys 中自動快取經常請求的檔案。

1.核心模式設定

與效能相關的 HTTP.sys 設定分為兩大類：快取管理和連線和請求管理。 所有登錄檔設定都儲存在以下注冊表項下：
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters

2.快取管理設定

HTTP.sys 提供的一個優點是核心模式快取。 如果響應在核心模式快取中，則可以完全從核心模式滿足 HTTP 請求，這會大幅降低處理請求所需的 CPU 開銷。 但是，IIS 10.0 的核心模式快取基於實體記憶體，項的開銷是其佔用的記憶體。
快取中的條目只有在使用時才有用。 但是，無論是否正在使用該條目，該條目始終使用實體記憶體。 你必須評估快取中某項的有用性 (通過考慮可用資源 (CPU 和實體記憶體) 以及工作負荷要求，從快取中為其提供服務所需的節省時間) 及其成本) (其成本。 HTTP.sys 嘗試在快取中僅保留有用的、主動訪問的項，但你可以通過優化特定工作負荷的 HTTP.sys 快取來提高 web 伺服器的效能。
下面是 HTTP.sys 核心模式快取的一些有用設定：

• UriEnableCache 預設值：1
  如果值為非零值，則啟用核心模式響應和片段快取。 對於大多數工作負荷，快取應保持啟用狀態。 如果需要很低的響應和碎片快取，請考慮禁用快取。
• UriMaxCacheMegabyteCount 預設值：0
  一個非零值，該值指定可用於核心模式快取的最大記憶體。 預設值為0，使系統能夠自動調整可用於快取的記憶體量。
• UriMaxUriBytes 預設值：262144位元組 (256 KB)
  核心模式快取中條目的最大大小。 不會快取大於此的響應或碎片。 如果有足夠的記憶體，請考慮增加限制。 如果記憶體有限，且大項 crowding 較小的項，則可能會降低限制。
• UriScavengerPeriod 預設值：120秒
  清理程式會定期掃描 HTTP.sys 快取，並刪除清除程式掃描之間未訪問的條目。 將清除週期設定為較高的值將減少清除清理的次數。 但是，快取記憶體使用量可能會增加，因為在快取中可以保留較舊、不經常訪問的條目。 將該時間段設定得過低會導致清除清理次數過多，並可能導致重新整理和快取改動過多。

3.使用者模式設定

本部分中的設定將影響 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簡介 。

4.NUMA 硬體的理想 CPU 設定

從 Windows 2016 開始，IIS 10.0 支援其執行緒池執行緒的自動理想 CPU 分配，以提高 NUMA 硬體的效能和可伸縮性。 此功能在預設情況下處於啟用狀態，可通過以下注冊表項進行配置：
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\ThreadPoolUseIdealCpu
啟用此功能後，IIS 執行緒管理器將盡最大努力基於當前負載在所有 NUMA 節點的所有 Cpu 之間平均分配 IIS 執行緒池執行緒。 通常情況下，建議將 NUMA 硬體的預設設定保持不變。

5.使用者模式快取行為設定

本部分介紹影響 IISÂ10.0 中的快取行為的設定。 使用者模式快取是作為一個模組來實現的，該模組偵聽整合管道引發的全域性快取事件。 若要完全禁用使用者模式快取，請從 applicationHost.config 的 System.webserver/globalModules 配置節中的已安裝模組列表中刪除 FileCacheModule ( # A0) 模組。
system.webserver/快取

6.壓縮行為設定

預設情況下，從7.0 開始的 IIS 壓縮靜態內容。 此外，在安裝 DynamicCompressionModule 時，會預設啟用動態內容壓縮。 壓縮可減少頻寬使用量，但會增大 CPU 使用率。 如果可能，壓縮內容快取在核心模式快取中。 從8.5 開始，IIS 允許為靜態和動態內容單獨控制壓縮。 靜態內容通常是指不會更改的內容，如 GIF 或 .HTM 檔案。 動態內容通常由指令碼或伺服器上的程式碼生成，即 ASP.NET 頁面。 您可以自定義任何特定擴充套件的分類為靜態或動態。
若要完全禁用壓縮，請從 applicationHost.config 的 System.webserver/globalModules 節中的模組列表中刪除 StaticCompressionModule 和 DynamicCompressionModule。

7.併發設定

ASP.NET 3.5

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

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

以下設定對於完全使用系統資源非常有用：

• maxConcurrentRequestPerCpu 預設值：5000
  此設定限制系統上同時執行的 ASP.NET 請求的最大數量。 預設值為保守以減少 ASP.NET 應用程式的記憶體佔用。 考慮在執行執行長時間同步 i/o 操作的應用程式的系統上增加此限制。 否則，使用者可能會遇到高延遲，因為在使用預設設定時，由於佇列限制超出了佇列限制，導致佇列或請求失敗。

ASP.NET 4.6

除了 maxConcurrentRequestPerCpu 設定外，ASP.NET 4.7 還提供了一些設定，以提高嚴重依賴於非同步操作的應用程式的效能。 可以在 aspnet.config 檔案中更改設定。

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

• percentCpuLimit 預設值：90將大量負載 (超出硬體) 功能時，此類情況下會出現一些可伸縮性問題。 此問題是由對非同步方案進行分配的性質導致的。 在這些情況下，將在非同步操作啟動時進行分配，並且在完成時將使用它。 在這段時間，itâs 非常可能將物件移動到第1代或第2代垃圾回收器。 發生這種情況時，增加負載會顯示每秒請求數增加 (rps) ，直到達到某個點。 傳遞該點後，GC 中花費的時間會開始成為一個問題，rps 將開始進行 dip，這會造成負面影響。 若要解決此問題，當 cpu 使用率超出 percentCpuLimit 設定時，請求將傳送到 ASP.NET 本機佇列。
• percentCpuLimitMinActiveRequestPerCpu 預設值： 100 CPU 限制 (percentCpuLimit 設定) 不是基於請求數，而是取決於請求的費用。 因此，可能只需要幾個佔用 CPU 的請求，這會導致在本機佇列中進行備份，使其不會從傳入請求中清空。 若要解決此 problme，可以使用 percentCpuLimitMinActiveRequestPerCpu 來確保在限制開始之前提供最少數量的請求。

影響 IIS 效能的其他問題

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

• 安裝不能識別快取的篩選器
  如果安裝的篩選器不能識別 HTTP 快取，將導致 IIS 完全禁用快取，從而導致效能不佳。 在 IISÂ6.0 之前編寫的 ISAPI 篩選器會導致此行為。
• 通用閘道器介面 (CGI) 請求
  出於效能方面的考慮，不建議在 IIS 中使用 CGI 應用程式來處理請求。 經常建立和刪除 CGI 程序涉及到很大的開銷。 更好的替代方法包括使用 FastCGI、ISAPI 應用程式指令碼、ASP 或 ASP.NET 指令碼。 每個選項都提供隔離。
  注意：
  1.所有設定更改完畢，需要重啟IIS。
  2.更多詳細設定，請參考微軟官方文件。