IIS應用程序池配置詳解及優化

參數說明

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.常規設置

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/緩存

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