參數說明
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.更多詳細設置，請參考微軟官方文檔。