引數說明
1.常規
| 屬性名稱 | 屬性詳解 |
|---|---|
| NET CLR 版本 | 配置應用程式池，以載入特定版本的 .NET CLR。選定的 CLR版本應與應用程式所使用的相應版本的 .NET Framework 對應。選擇“無託管程式碼”將導致所有的 ASP.NET 請求失敗。 |
| 佇列長度 | HTTP.sys 將針對應用程式池排隊的最大請求數。如果佇列已滿，新請求將收到 503“服務不可用”的響應。預設佇列長度設定是1000，範圍在10-65535 之間。 |
| 名稱 | 應用程式池名稱是應用程式池的唯一識別符號。 |
| 啟動模式 | 將應用程式池配置為在按需執行模式或始終執行模式下執行。 |
| 啟用 32 位應用程式 | 如果針對 64 位作業系統上的應用程式池將該屬性設為 True,則為應用程式池提供服務的工作程式將處於 WOW64 （Windows on Windows64）模式。WOW64模式下的程式是僅載入 32 位應用程式的 32 位程式。 |
| 託管管道模式 | 將 ASP.NET 配置成作為 ISAPI 擴充套件並以經典模式來執行。在後一種情況下，託管程式碼整合到請求處理管道中。 |
Classic模式：指的是與IIS 6或者之前版本保持相容的一種模式，一個典型問題就是，在處理ASP.NET這種動態網站的時候，它是通過一個所謂的ISAPI程式，作為外掛的方式來工作的。針對不同的動態應用程式（例如ASP,PHP等），會需要不同的ISAPI。
Integrated模式：這種全新的模式，允許我們將ASP.NET更好地與IIS整合，甚至允許我們在ASP.NET中編寫一些功能（例如Module）來改變IIS的行為（擴充套件）。整合的好處是，不再通過ISAPI的方式，提高了速度和穩定性。至於擴充套件，則可以使得我們對於IIS，以及其他型別的請求有更多的控制。
2.CUP
| 屬性名稱 | 屬性詳解 |
|---|---|
| 處理器關聯掩碼 | 強制此應用程式池的工作程式在特定 CPU 上執行的十六進位制掩碼。如果啟用了處理器關聯，則值 0 將導致錯誤。 |
| 處理器關聯掩碼（64位選項） | 為64位計算機制定強制此應用程式池的工作程式在特定 CPU 上執行的高順序 DWORD 十六進位制掩碼。在 64 位計算機上，smpProcessorAffinityMask 特性包含處理器掩碼的低順序 DWORD ，而 smpProcessorAffinityMask2 特性包含處理器掩碼的高順序 DWORD。 |
| 限制（百分比） | 配置允許應用程式池中的工作程式在" CPU 限制間隔 "屬性指示的時間段內使用的 CPU 時間的最大百分比。如果超過“ CPU 限制 ”屬性設定的限制，系統將向事件日誌寫入一個事件，並且可能觸發一組可選事件（由“CPU 限制操作”屬性決定）。如果將此屬性的值設為 0 ，將禁止將工作程式限制為 CPU 時間的百分比。 |
| 限制操作 | 如果設定為"NoAction"，將生成一個事件日誌條目。如果設定為“KillW3WP”，則將在重設間隔期間關閉應用程式池並生成一個事件日誌條目。如果設定為“ Throttle ”，則 CPU 使用率將限制為限制中設定的值。不使用限制間隔，並且生成一個事件日誌條目。如果設定為“ ThrottleUnderLoad ”，則只有在爭用 CPU 時，才限制 CPU 使用率。不使用限制間隔，並且生成一個事件日誌條目。 |
| 限制間隔（分鐘） | 指定用於應用程式池的 CPU 監視和限制的重設期限（以分鐘為單位）。如果自上次程式計帳重設以來所經過的分鐘數等於此屬性指定的分鐘數，IIS 將重設日誌和限制間隔的 CPU 計時器。將此屬性的值設為 0 將禁用 CPU 監視。 |
| 已啟用處理器關聯 | 如果設為 True ，“處理器關聯掩碼”屬性會強制為此應用程式池提供服務的工作程式在特定的 CPU 上執行。這樣便可以在多處理伺服器中有效使用 CPU 快取。 |
3.回收
| 屬性名稱 | 屬性詳解 |
|---|---|
| 發生配置更改時禁止回收 | 如果為 True，應用程式池在發生配置更改時將不會回收。 |
| 固定時間間隔（分鐘） | 一個時間段（以分鐘為單位），超過該時間後，應用程式池將回收。值為 0 意味著應用程式池不會按固定間隔回收。 |
| 禁止重疊回收 | 如果為 True ,將發生應用程式池回收，以便在建立另一個工作程式之前退出現有工作程式。如果工作程式載入不支援多個例項的應用程式，請將該屬性設為True。 |
| 請求限制 | 應用程式池在回收之前可以處理的最大請求數。如果值為0，則表示應用程式池可以處理的請求數沒有限制。 |
| 生成回收事件日誌條目 | 每發生一次指定的回收事件時便生成一個事件日誌條目。 |
| ISAPI 報告了非正常狀態 | 如果為True，則當應用程式池由於 ISAPI 擴充套件將其自身報告為非正常而進行回收時，系統將生成一個事件日誌條目。 |
| 超出請求限制 | 如果為 True，則當應用程式池在超出其請求限制後進行回收時，系統將生成一個事件日誌條目。 |
| 超出虛擬記憶體限制 | 如果為True，則當應用程式池在超出其虛擬記憶體限制後進行回收時，系統將生成一個事件日誌條目。 |
| 固定時間間隔 | 如果為True，則當應用程式池按計劃的間隔進行回收時，系統將生成一個事件日誌條目。 |
| 手動回收 | 如果為True，則當手動回收應用程式池時，系統將生成一個事件日誌條目。 |
| 特定時間 | 如果為True，則當應用程式池在計劃的時間進行回收時，系統將生成一個事件日誌條目。 |
| 已超出專用記憶體限制 | 如果為True，則當應用程式池在超出其專用記憶體限制後進行回收時，系統將生成一個事件日誌條目。 |
| 應用程式池配置已更改 | 如果為True，則當應用程式池由於其配置發生更改而回收時，系統將生成一個事件日誌條目。 |
| 特定時間 | 應用程式池進行回收的一組特定的本地時間（24小時制）。 |
| 虛擬記憶體限制（KB） | 工作程式可以使用的最大虛擬記憶體量（以 KB 為單位），超過此記憶體量，將導致應用程式池回收。如果值為 0 ，則表示沒有限制。 |
| 專用記憶體限制（KB） | 工作程式可以使用的最大專用記憶體量（以 KB 為單位），超出此記憶體量，將導致應用程式池回收。如果值為0，則表示沒有限制。 |
4.程式孤立
| 屬性名稱 | 屬性詳解 |
|---|---|
| 可執行檔案 | 當工作程式被廢棄（孤立）時執行的可執行檔案。例如，“C:\dbgtools\ntsd.exe”將呼叫 NTSD 來除錯工作程式故障。 |
| 可執行檔案引數 | 當工作程式被廢棄（孤立）時所執行的可執行檔案的引數。例如，如果 NTSD 是為除錯工作程式故障而呼叫的可執行檔案，則“-g -p %1%”適用。 |
| 已啟用 | 如果設為True ，則無響應的工作程式將被廢棄（孤立），而不是終止。可以使用此功能來除錯工作程式故障。 |
5.程式模型
| 屬性名稱 | 屬性詳解 |
|---|---|
| Ping 間隔（秒） | 兩次向為此應用程式池提供服務的工作程式傳送健康狀況監視 ping 所間隔的時間段（以秒為單位）。 |
| Ping 最大響應時間（秒） | 為工作程式指定的、響應健康狀況監視 ping 的最長時間（以秒為單位）。如果工作程式不響應，將被終止。 |
| 標識 | 配置應用程式池以作為內建賬戶或特定的使用者標識執行，內建賬戶也就是“應用程式池標識”（推薦）、“網路服務”、“本地系統”、“本地服務”。 |
| 關閉時間限制（秒） | 為工作程式指定的、完成處理請求並關閉的時間段（以秒為單位）。如果工作程式超過關閉的時間限制，將被終止。 |
| 載入使用者配置檔案 | 此設定指定 IIS 是否為應用程式池標識載入使用者配置檔案。當此值為 True 時，IIS為應用程式池標識載入使用者配置檔案。如果您需要像 IIS 6.0 那樣不為應用程式池標識載入使用者配置檔案，則此值設定為 false。 |
| 空閒超時操作 | 達到空閒超時持續時間後要執行什麼操作。 |
| 啟動時間限制（秒） | 為工作程式指定的、啟動並進行初始化的時間段（以秒為單位）。如果工作程式初始化時間超過啟動時間限制，將被終止。 |
| 啟用 Ping | 如果為 True，系統將定期對為此應用程式池提供服務的工作程式執行ping 操作，以確保這些工作程式仍及時響應。此過程稱為健康狀況監視。 |
| 生成程式模型時間日誌條目 | 為每次發生的指定程式模型事件生成一個事件日誌條目。 |
| 空閒超時已到 | 如果為 True，則當應用程式池在超出其空閒時限制後關閉時，系統將生成一個事件日誌條目。 |
| 閒置超時（分鐘） | 工作程式在關閉之前可以保持閒置狀態的時間（以分鐘為單位）。如果某個工作程式既未處理請求，也未收到任何新的請求，則將進入閒置狀態。 |
| 最大工作程式數 | 可用來處理對應程式池的請求的最大工作程式數。如果此數字大於 1，則應用程式池為“Web 園”。在 NUMA 感知系統上，如果此數字為 0，則為獲得最佳效能，IIS 將啟動與 NUMA 節點一樣多的工作程式。 |
標識詳解：
- 本地系統： 具有高許可權的受信任帳戶，還具有對網路資源的訪問許可權。
- 網路服務： 用於執行標準的最小特權服務的受限或有限服務帳戶。 此帳戶具有比本地系統帳戶更少的許可權。 此帳戶可以訪問網路資源。
- 本地服務： 受限制或有限的服務帳戶，與網路服務類似，旨在執行標準的最小特權服務。 此帳戶無權訪問網路資源。
- ApplicationPoolIdentity： 當建立新的應用程式池時，IIS 將建立一個虛擬帳戶，該帳戶具有新應用程式池的名稱，並在此帳戶下執行應用程式池工作程式。 這也是一個具有最小特權的帳戶。
- 自定義帳戶： 除了這些內建帳戶之外，還可以通過指定使用者名稱和密碼來使用自定義帳戶。
6.快速故障防護
| 屬性名稱 | 屬性詳解 |
|---|---|
| 服務不可用響應型別 | 如果設為 HttpLevel,那麼當應用程式池停止時， HTTP.sys 將返回 HTTP 503 錯誤。如果設為 TcpLevel，HTTP.sys 將重置連線。如果負載平衡器識別其中一種響應型別，並隨後重定向該型別，則此設定非常有用。 |
| 故障間隔（分鐘） | 應用程式池發生指定數量的工作程式崩潰（最大故障數）的最短時間間隔（以分鐘為單位）。如果低於此間隔，應用程式池將被快速故障防護功能關閉。 |
| 關閉可執行檔案 | 當應用程式池被快速故障防護功能關閉時所執行的可執行檔案。可以使用它來配置負載平衡器，將此應用程式池的通訊重定向至其他伺服器。 |
| 關閉可執行檔案引數 | 當應用程式池被快速故障防護功能關閉時執行的可執行檔案的引數。 |
| 已啟用 | 如果設為 True，則當在指定的時間段（故障間隔）內出現指定數量的工作程式崩潰（最大故障數）的情況時，應用程式池將被關閉。預設情況下，如果在5分鐘的間隔內發生5次崩潰，應用程式池將被關閉。 |
| 最大故障數 | 應用程式池被快速故障防護功能關閉之前允許的最大工作程式崩潰數。 |
應用程式池優化配置
1.常規設定
- 佇列長度： 預設值1000，將原來的佇列長度改為 65535。
- 啟動32位應用程式：預設值False，改為True。
- 託管管道模式：Integrated 或 Classsic。
2.回收設定
- 禁用重疊回收。
- 設定為特定時間=true，每天晚上04：00分回收。
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/快取
| Attribute | 說明 | 預設 |
|---|---|---|
| 已啟用 | 當設定為 False時，禁用使用者模式的 IIS 快取。 如果快取命中率非常小，則可以完全禁用快取，以避免與快取程式碼路徑相關聯的開銷。 禁用使用者模式快取不會禁用核心模式快取。 | 正確 |
| enableKernelCache | 當設定為 False時禁用核心模式快取。 | 正確 |
| maxCacheSize | 將 IIS 使用者模式快取大小限制為指定的大小（以 Mb 為單位）。 IIS 根據可用記憶體調整預設值。 根據經常訪問的檔案集的大小以及 RAM 或 IIS 程式地址空間的大小，仔細選擇值。 | 0 |
| maxResponseSize | 將檔案快取到指定大小。 實際值取決於資料集中最大檔案的數量和大小，以及可用 RAM。 快取大型、頻繁請求的檔案可以降低 CPU 使用量、磁碟訪問和相關的延遲。 | 262144 |
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.更多詳細設定，請參考微軟官方文件。