IIS应用程序池配置详解及优化
（给DotNet加星标，提升.Net技能）
转自：故人与猫 cnblogs.com/Drock/p/14149485.html
参数说明
1、常规
Classic模式：指的是与IIS 6或者之前版本保持兼容的一种模式，一个典型问题就是，在处理ASP.NET这种动态网站的时候，它是通过一个所谓的ISAPI程序，作为插件的方式来工作的。针对不同的动态应用程序（例如ASP,PHP等），会需要不同的ISAPI。
Integrated模式：这种全新的模式，允许我们将ASP.NET更好地与IIS集成，甚至允许我们在ASP.NET中编写一些功能（例如Module）来改变IIS的行为（扩展）。集成的好处是，不再通过ISAPI的方式，提高了速度和稳定性。至于扩展，则可以使得我们对于IIS，以及其他类型的请求有更多的控制。
2、CUP
3、回收
4、进程孤立
5、进程模型
标识详解：
本地系统：具有高权限的受信任帐户，还具有对网络资源的访问权限。
网络服务：用于运行标准的最小特权服务的受限或有限服务帐户。此帐户具有比本地系统帐户更少的权限。此帐户可以访问网络资源。
本地服务：受限制或有限的服务帐户，与网络服务类似，旨在运行标准的最小特权服务。此帐户无权访问网络资源。
ApplicationPoolIdentity：当创建新的应用程序池时，IIS 将创建一个虚拟帐户，该帐户具有新应用程序池的名称，并在此帐户下运行应用程序池工作进程。这也是一个具有最小特权的帐户。
自定义帐户：除了这些内置帐户之外，还可以通过指定用户名和密码来使用自定义帐户。
6、快速故障防护
应用程序池优化配置
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/缓存
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 性能：
1、安装不能识别缓存的筛选器
如果安装的筛选器不能识别 HTTP 缓存，将导致 IIS 完全禁用缓存，从而导致性能不佳。在 IISÂ6.0 之前编写的 ISAPI 筛选器会导致此行为。
2、通用网关接口 (CGI) 请求
出于性能方面的考虑，不建议在 IIS 中使用 CGI 应用程序来处理请求。经常创建和删除 CGI 进程涉及到很大的开销。更好的替代方法包括使用 FastCGI、ISAPI 应用程序脚本、ASP 或 ASP.NET 脚本。每个选项都提供隔离。
注意：
1、所有设置更改完毕，需要重启IIS。
2、更多详细设置，请参考微软官方文档。
- EOF -
看完本文有收获？请转发分享给更多人
推荐关注「DotNet」，提升.Net技能
点赞和在看就是最大的支持❤️