优化 IIS 10.0
Windows Server 2022 随附 Internet Information Services (IIS) 10.0。 它使用类似于 IIS 8.5 和 IIS 7.0 的进程模型。 内核模式 Web 驱动程序 (http.sys) 接收并路由 HTTP 请求，并满足来自其响应缓存的请求。 工作进程注册 URL 子空间，http.sys 请求路由到适当的进程（或应用程序池的进程集）。
HTTP.sys 负责连接管理和请求处理。 可以从 HTTP.sys 缓存中提供请求，也可以将其传递给工作进程以供进一步处理。 可以配置多个工作进程，从而以更低成本提供隔离。 有关请求处理工作原理的详细信息，请参阅下图：
HTTP.sys 包括响应缓存。 当请求与响应缓存中的条目匹配时，HTTP.sys 会直接从内核模式发送缓存响应。 某些 Web 应用程序平台（例如 ASP.NET）提供了一些机制，使任何动态内容都能缓存在内核模式缓存中。 IIS 10.0 中的静态文件处理程序会自动缓存 http.sys 中频繁请求的文件。
由于 Web 服务器具有内核模式和用户模式组件，因此必须优化这两个组件才能获得最佳性能。 因此，针对特定工作负载优化 IIS 10.0 包括配置以下内容：
HTTP.sys 和关联的内核模式缓存
工作进程和用户模式 IIS，包括应用程序池配置
影响性能的某些优化参数
以下部分讨论如何配置 IIS 10.0 的内核模式和用户模式方面。
内核模式设置
与性能相关的 HTTP.sys 设置分为两大类：缓存管理、连接和请求管理。 所有注册表设置都存储在以下注册表项下：
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters
注意 如果 HTTP 服务已在运行，则必须将其重启才能使更改生效。
缓存管理设置
HTTP.sys 提供的一种好处是内核模式缓存。 如果响应在内核模式缓存中，则可以完全从内核模式满足 HTTP 请求，这大大降低了处理请求的 CPU 成本。 但是，IIS 10.0 的内核模式缓存基于物理内存，而条目的成本是其占用的内存。
缓存中的条目仅在使用时才有用。 但是，无论是否在使用条目，条目始终都会消耗物理内存。 必须通过考虑可用资源（CPU 和物理内存）和工作负载需求，评估缓存中某个项的有用性（能够从缓存中提供该项而出现的节省情况）及其成本（占用的物理内存）。 HTTP.sys 尝试只保留缓存中有用的主动访问项，但你可以通过针对特定工作负载优化 HTTP.sys 缓存来提升 Web 服务器的性能。
下面是 HTTP.sys 内核模式缓存的一些有用设置：
UriEnableCache 默认值：1
非零值启用内核模式响应和片段缓存。 对于大多数工作负载，缓存都应保持启用状态。 如果预期响应和片段缓存非常低，请考虑禁用缓存。
UriMaxCacheMegabyteCount 默认值：0
一个指定可用于内核模式缓存的最大内存的非零值。 默认值 0 使系统能够自动调整缓存可用的内存量。
注意：指定大小仅设置最大值，系统可能不会让缓存增长到最大集大小。
Â
UriMaxUriBytes 默认值：262144 字节 (256 KB)
内核模式缓存中条目的最大大小。 大于此值的响应或的片段不会缓存。 如果有足够的内存，请考虑提高限制。 如果内存有限，并且大型条目排挤较小条目，则降低限制可能有所帮助。
UriScavengerPeriod 默认值：120 秒
清除器会定期扫描 HTTP.sys 缓存，并删除清除器扫描之间未访问的条目。 将清除器周期设置为较高的值可减少清除器扫描次数。 但是，缓存内存使用量可能会增加，因为较早的、访问频率较低的条目可能会保留在缓存中。 将时间段设置得太短会导致清除器扫描更频繁，并可能导致过多刷新和缓存流失。
请求和连接管理设置
在 Windows Server 2022 中，HTTP.sys 自动管理连接。 以下注册表设置已不再使用：
MaxConnections
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\MaxConnectionsIdleConnectionsHighMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsHighMarkIdleConnectionsLowMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsLowMarkIdleListTrimmerPeriod
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleListTrimmerPeriodRequestBufferLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\RequestBufferLookasideDepthInternalRequestLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\InternalRequestLookasideDepth
用户模式设置
本部分中的设置会影响 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 简介。
NUMA 硬件的理想 CPU 设置
从 Windows Server 2016 开始，IIS 10.0 支持自动为其线程池线程分配理想 CPU，以增强 NUMA 硬件上的性能和可伸缩性。 此功能默认处于启用状态，可通过以下注册表项进行配置：
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\ThreadPoolUseIdealCpu
启用此功能后，IIS 线程管理器会尽力根据当前负载在所有 NUMA 节点中的所有 CPU 之间均匀分配 IIS 线程池线程。 通常而言，对于 NUMA 硬件，建议保持此默认设置不变。
注意：理想的 CPU 设置不同于应用程序池的 CPU 设置中引入的工作进程 NUMA 节点分配设置（numaNodeAssignment 和 numaNodeAffinityMode）。 理想的 CPU 设置会影响 IIS 分配其线程池线程的方式，而工作进程 NUMA 节点分配设置决定工作进程在哪个 NUMA 节点上启动。
用户模式缓存行为设置
本部分介绍影响 IIS 10.0 中缓存行为的设置。 用户模式缓存以模块的形式实现，该模块侦听由集成管道引发的全局缓存事件。 若要完全禁用用户模式缓存，请在 applicationHost.config 的 system.webServer/globalModules 配置部分中，从已安装模块列表中移除 FileCacheModule (cachfile.dll) 模块。
system.webServer/caching
| 属性 | 说明 | 默认 |
|---|---|---|
| Enabled | 在设置为 False 时禁用用户模式 IIS 缓存。 当缓存命中率非常小时，可以完全禁用缓存，避免与缓存代码路径相关的开销。 禁用用户模式缓存不会禁用内核模式缓存。 | True |
| enableKernelCache | 设置为 False 时禁用内核模式缓存。 | True |
| maxCacheSize | 将 IIS 用户模式缓存大小限制为指定大小（以兆字节为单位）。 IIS 根据可用内存调整默认值。 根据经常访问的文件集大小与 RAM 或 IIS 进程地址空间量，仔细选择该值。 | 0 |
| maxResponseSize | 缓存文件，一直到指定大小。 实际值取决于数据集中最大文件的数量和大小与可用 RAM。 缓存频繁请求的大型文件可减少 CPU 使用率、磁盘访问和相关延迟。 | 262144 |
压缩行为设置
默认情况下，从 7.0 开始的 IIS 会压缩静态内容。 此外，安装 DynamicCompressionModule 时会默认启用动态内容压缩。 压缩可减少带宽使用量，但会增加 CPU 使用率。 如有可能，压缩的内容将缓存在内核模式缓存中。 从 8.5 开始，IIS 支持独立控制静态和动态内容的压缩。 静态内容通常是指不会更改的内容，例如 GIF 或 HTM 文件。 动态内容通常由服务器上的脚本或代码生成，即 ASP.NET 页面。 可以将任何特定扩展的分类自定义为静态或动态。
若要完全禁用压缩，请从 applicationHost.config 的 system.webServer/globalModules 部分的模块列表中移除 StaticCompressionModule 和 DynamicCompressionModule。
system.webServer/httpCompression
| 属性 | 说明 | 默认 |
|---|---|---|
| staticCompression-EnableCpuUsage staticCompression-DisableCpuUsage dynamicCompression-EnableCpuUsage dynamicCompression-DisableCpuUsage |
如果当前 CPU 使用率百分比高于或低于指定限制，则启用或禁用压缩。 从 IIS 7.0 开始，如果稳定状态 CPU 超过禁用阈值，则会自动禁用压缩。 如果 CPU 低于启用阈值，则会启用压缩。 |
分别为 50、100、50 和 90 |
| 目录 | 指定临时存储和缓存的压缩版本静态文件的目录。 如果经常访问此目录，请考虑将此目录移出系统驱动器。 | %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files |
| doDiskSpaceLimiting | 指定是否存在所有压缩文件可占用磁盘空间量的限制。 压缩文件存储在 directory 属性指定的压缩目录中。 | True |
| maxDiskSpaceUsage | 指定压缩文件可在压缩目录中占用的磁盘空间字节数。 如果所有压缩内容的总大小过大，则可能需要增加此设置。 |
100 MB |
system.webServer/urlCompression
| 属性 | 说明 | 默认 |
|---|---|---|
| doStaticCompression | 指定是否压缩静态内容。 | True |
| doDynamicCompression | 指定是否压缩动态内容。 | True |
注意
对于运行平均 CPU 使用率较低的 IIS 10.0 的服务器，请考虑为动态内容启用压缩，尤其是具有大型响应的情况下。 这应先在测试环境中完成，以通过基线评估对 CPU 使用率的影响。
优化默认文档列表
默认文档模块会处理目录根目录的 HTTP 请求，并将其转换为对特定文件（如 Default.htm 或 Index.htm）的请求。 平均而言，Internet 上大约 25% 的请求都会通过默认文档路径。 对于各个站点，这一点差异很大。 当 HTTP 请求未指定文件名时，默认文档模块会在文件系统中搜索允许的默认文档列表中的每个名称。 这会对性能产生负面影响，尤其是在访问内容需要进行网络往返或触及磁盘时。
可以通过有选择地禁用默认文档以及文档列表缩减或排序来避免开销。 对于使用默认文档的网站，应将列表减少为仅限使用的默认文档类型。 此外，对列表进行排序，使其以最常访问的默认文档文件名开头。
可以在 applicationHost.config 中的位置标记内自定义配置或直接在内容目录中插入 web.config 文件，从而有选择性地设置特定 URL 的默认文档行为。 这允许混合方法，该方法仅在必要时启用默认文档，并将列表设置为每个 URL 的正确文件名。
若要完全禁用默认文档，请从 applicationHost.config 的 system.webServer/globalModules 部分的模块列表中移除 DefaultDocumentModule。
system.webServer/defaultDocument
| 属性 | 说明 | 默认 |
|---|---|---|
| enabled | 指定启用默认文档。 | True |
<files> 元素 |
指定配置为默认文档的文件名。 | 默认列表为 Default.htm、Default.asp、Index.htm、Index.html、Iisstart.htm 和 Default.aspx。 |
集中二进制日志记录
当服务器会话下有许多 URL 组时，为单个 URL 组创建数百个经过格式设置的日志文件并将日志数据写入磁盘这一过程可能会快速消耗宝贵的 CPU 和内存资源，从而产生性能和可伸缩性问题。 集中式二进制日志记录可最大程度地减少用于日志记录的系统资源量，同时为有需要的组织提供详细日志数据。 分析二进制格式日志需要后处理工具。
可以通过将 centralLogFileMode 特性设置为 CentralBinary 并将 enabled 属性设置为 True 来启用集中二进制日志记录。 请考虑将集中日志文件的位置从系统分区移动到专用日志记录驱动器上，从而避免系统活动和日志记录活动之间的争用。
system.applicationHost/log
| 属性 | 说明 | 默认 |
|---|---|---|
| centralLogFileMode | 指定服务器的日志记录模式。 将此值更改为 CentralBinary 即可启用集中二进制日志记录。 | 站点 |
system.applicationHost/log/centralBinaryLogFile
| 属性 | 说明 | 默认 |
|---|---|---|
| enabled | 指定是否启用集中二进制日志记录。 | False |
| 目录 | 指定写入日志条目的目录。 | %SystemDrive%\inetpub\logs\LogFiles |
应用程序和站点优化
以下设置与应用程序池和站点优化相关。
system.applicationHost/applicationPools/applicationPoolDefaults
| 属性 | 说明 | 默认 |
|---|---|---|
| queueLength | 向 HTTP.sys 指示在拒绝未来请求之前有多少请求在应用程序池中排队。 如果超出此属性的值，IIS 会拒绝后续请求并显示 503 错误。 如果观察到 503 错误，请考虑增加与高延迟后端数据存储通信的应用程序的此值。 |
1000 |
| enable32BitAppOnWin64 | 如果为 True，则支持 32 位应用程序在具有 64 位处理器的计算机上运行。 如果担心内存消耗，请考虑启用 32 位模式。 由于指针大小和指令大小较小，因此 32 位应用程序使用的内存比 64 位应用程序少。 在 64 位计算机上运行 32 位应用程序的缺点是用户模式地址空间限制为 4 GB。 |
False |
system.applicationHost/sites/VirtualDirectoryDefault
| 属性 | 说明 | 默认 |
|---|---|---|
| allowSubDirConfig | 指定 IIS 是在低于当前级别的内容目录中查找 web.config 文件 (True)，还是不在低于当前级别的内容目录中查找 web.config 文件 (False)。 通过施加一个简单的限制（仅允许在虚拟目录中进行配置），IIS 10.0 便可以知道，除非 /<name>.htm 是虚拟目录，否则就不应查找配置文件。 跳过其他文件操作可显著提升具有大量随机访问静态内容的网站的性能。 | True |
管理 IIS 10.0 模块
IIS 10.0 已分解为多个用户可扩展的模块，以支持模块化结构。 这种分解成本很小。 对于每个模块，集成管道必须为与该模块相关的每个事件调用该模块。 无论模块是否必须执行任何工作，都会发生这种情况。 可以通过移除与特定网站不相关的所有模块来节省 CPU 周期和内存。
针对简单静态文件进行优化的 Web 服务器可能仅包含以下五个模块：UriCacheModule、HttpCacheModule、StaticFileModule、AnonymousAuthenticationModule 和 HttpLoggingModule。
若要从 applicationHost.config 中移除模块，请从 system.webServer/handlers 和 system.webServer/modules 部分中移除对模块的所有引用，并在 system.webServer/globalModules 中移除模块声明。
经典 ASP 设置
处理经典 ASP 请求的主要成本包括初始化脚本引擎、将请求的 ASP 脚本编译为 ASP 模板，以及在脚本引擎上执行模板。 虽然模板执行成本取决于所请求的 ASP 脚本的复杂性，但 IIS 经典 ASP 模块可以在内存中缓存脚本引擎，并在内存和磁盘中缓存模板（仅限内存中模板缓存溢出时），以提高 CPU 受限场景下的性能。
以下设置用于配置经典 ASP 模板缓存和脚本引擎缓存，并且不会影响 ASP.NET 设置。
system.webServer/asp/cache
| 属性 | 说明 | 默认 |
|---|---|---|
| diskTemplateCacheDirectory | 当内存中缓存溢出时，ASP 用于存储已编译模板的目录名称。 建议：设置为不经常使用的目录，例如未与操作系统、IIS 日志或其他经常访问的内容共享的驱动器。 |
%SystemDrive%\inetpub\temp\ASP Compiled Templates |
| maxDiskTemplateCacheFiles | 指定可在磁盘上缓存的已编译 ASP 模板的最大数。 建议：设置为最大值 0x7FFFFFFF。 |
2000 |
| scriptFileCacheSize | 此特性指定可在内存中缓存的已编译 ASP 模板的最大数。 建议：至少设置为应用程序池提供的经常请求的 ASP 脚本数。 如有可能，尽量设置为内存限制允许的最大 ASP 模板数。 |
500 |
| scriptEngineCacheMax | 指定将在内存中保持缓存的最大脚本引擎数。 建议：至少设置为应用程序池提供的经常请求的 ASP 脚本数。 如果可能，尽量设置为内存限制允许的最大脚本引擎数。 |
250 |
system.webServer/asp/limits
| 属性 | 说明 | 默认 |
|---|---|---|
| processorThreadMax | 指定 ASP 可以为每个处理器创建的最大工作线程数。 如果当前设置不足以处理负载，因而可能会导致在处理请求时出错或导致 CPU 资源使用率不足，则增加此值。 | 25 |
system.webServer/asp/comPlus
| 属性 | 说明 | 默认 |
|---|---|---|
| executeInMta | 如果在 IIS 提供 ASP 内容时检测到错误或故障，则设置为 True。 例如，当托管多个独立站点，而每个站点在其自己的工作进程下运行时，便可能发生这种情况。 通常从事件查看器中的 COM+ 报告错误。 此设置在 ASP 中启用多线程单元模型。 | False |
ASP.NET 并发设置
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 当此类场景负载过大（超出硬件功能范围）时，异步请求可能出现一些可伸缩性问题。 问题在于异步场景中的分配性质。 在这些情况下，异步操作启动时便会进行分配，并在完成时使用分配。 到那时，这些对象很可能已被 GC 移至第 1 代或第 2 代。 发生这种情况时，增加负载将显示每秒请求数 (rps) 增加，直至到达某个点。 通过这个点后，在 GC 中花费的时间将开始变成问题，而 rps 将开始下降，并产生负面缩放效应。 为解决此问题，当 CPU 使用率超过 percentCpuLimit 设置时，请求将发送到 ASP.NET 本机队列。
- percentCpuLimitMinActiveRequestPerCpu 默认值：100 CPU 限制（percentCpuLimit 设置）不基于请求数，而是基于请求的成本高低。 因此，可能只有几个 CPU 密集型请求导致本机队列中的备份，除了传入请求之外，无法将其清空。 为解决此问题，可以使用 percentCpuLimitMinActiveRequestPerCpu 来确保在启动限制之前提供最少的请求数。
工作进程和回收选项
可以配置用于回收 IIS 工作进程的选项，并为严重情况或事件提供实际解决方案，而无需干预或者重置服务或计算机。 此类情况和事件包括内存泄漏、内存负载增加或者工作进程无响应或空闲。 一般情况下，可能不需要回收选项，可以关闭回收，也可以将系统配置为很少回收。
可以向 recycling/periodicRestart 元素添加特性，从而为特定应用程序启用进程回收。 回收事件可由多种事件触发，包括内存使用情况、固定请求数和固定时间段。 回收工作进程时，系统会排空排队和正在执行的请求，同时启动一个新进程来为新请求提供服务。 recycling/periodicRestart 元素针对每个应用程序，这意味着下表中的每种特性都针对每个应用程序进行分区。
system.applicationHost/applicationPools/ApplicationPoolDefaults/recycling/periodicRestart
| 属性 | 说明 | 默认 |
|---|---|---|
| 内存 | 如果虚拟内存消耗超过指定限制（以 KB 为单位），则启用进程回收。 对于具有 2 GB 小地址空间的 32 位计算机，这是一项很有用的设置。 这有助于避免因内存不足错误而失败的请求。 | 0 |
| privateMemory | 如果专用内存分配超过指定限制（以 KB 为单位），则启用进程回收。 | 0 |
| 请求 | 在一定数量的请求后启用进程回收。 | 0 |
| time | 在指定时间段后启用进程回收。 | 29:00:00 |
动态工作进程页面输出优化
从 Windows Server 2012 R2 中开始，IIS 提供了将工作进程配置为在空闲一段时间后暂停的选项（此外还具有终止选项，该选项自 IIS 7 以来一直存在）。
空闲工作进程页面输出和空闲工作进程终止功能的主要用途是节省服务器上的内存利用率，因为一个站点即使只是坐在那里进行侦听，也会消耗大量内存。 根据站点上使用的技术（静态内容与 ASP.NET 与其他框架），使用的内存可能在大约 10 MB 到数百 MB 之间，这意味着如果服务器配置了许多站点，为站点找出最有效的设置可以极大地提升活动站点和已暂停站点的性能。
在具体说明前，我们必须记住，如果没有内存限制，那么最好就是将站点设置为永不暂停或终止即可。 毕竟，如果工作进程是计算机上的唯一工作进程，终止该进程则价值不大。
注意
如果站点运行不稳定的代码（例如内存泄漏的代码或其他不稳定的代码），将站点设置为空闲时终止可能是修复代码 bug 的暂时性替代方法。 这不是我们所鼓励的方法，但在紧要关头，当更永久的解决方案还在开发时，使用这一功能作为清理机制可能更好。
要考虑的另一个因素是，如果站点使用大量内存，则暂停进程本身会造成损失，因为计算机必须将工作进程使用的数据写入磁盘。 如果工作进程要使用大量内存，则将其暂停的成本可能比等待其开始备份的成本更高。
为了充分利用工作进程暂停功能，你需要查看每个应用程序池中的站点，并决定哪些应暂停，哪些应终止，以及哪些应无限期处于活动状态。 对于每项操作和每个站点，你需要确定理想的超时期限。
理想情况下，要配置为暂停或终止的站点每天都有访客，但又不足以保证让其始终保持活动状态。 这些网站通常每天大约有 20 位唯一的访客或更少。 可以使用站点的日志文件分析流量模式，并计算平均每日流量。
请记住，将特定用户连接到站点后，他们通常会在站点上停留至少一段时间，并发出其他请求，因此仅计算每日请求数可能无法准确反映实际流量模式。 若要获得更准确的读数，还可以使用 Microsoft Excel 等工具来计算请求之间的平均时间。 例如：
| Number | 请求 URL | 请求时间 | 增量 |
|---|---|---|---|
| 1 | /SourceSilverLight/Geosource.web/grosource.html | 10:01 | |
| 2 | /SourceSilverLight/Geosource.web/sliverlight.js | 10:10 | 0:09 |
| 3 | /SourceSilverLight/Geosource.web/clientbin/geo/1.aspx | 10:11 | 0:01 |
| 4 | /lClientAccessPolicy.xml | 10:12 | 0:01 |
| 5 | / SourceSilverLight/GeosourcewebService/Service.asmx | 10:23 | 0:11 |
| 6 | / SourceSilverLight/Geosource.web/GeoSearchServer...¦. | 11:50 | 1:27 |
| 7 | /rest/Services/CachedServices/Silverlight_load_la...¦ | 12:50 | 1:00 |
| 8 | /rest/Services/CachedServices/Silverlight_basemap...¦. | 12:51 | 0:01 |
| 9 | /rest/Services/DynamicService/ Silverlight_basemap...¦. | 12:59 | 0:08 |
| 10 | /rest/Services/CachedServices/Ortho_2004_cache.as... | 13:40 | 0:41 |
| 11 | /rest/Services/CachedServices/Ortho_2005_cache.js | 13:40 | 0:00 |
| 12 | /rest/Services/CachedServices/OrthoBaseEngine.aspx | 13:41 | 0:01 |
然而，困难的部分是弄清楚要应用哪种设置才合理。 在本例中，站点从用户获取一组请求，上表显示，在 4 小时的时段内总共发生了 4 次唯一会话。 对于应用程序池的工作进程暂停的默认设置，站点将在 20 分钟默认超时后终止，这意味着其中每位用户都将经历站点启动周期。 这使其成为工作进程暂停的理想候选项，因为在大多数情况下，站点处于空闲状态，因此暂停会节省资源，并让用户几乎能够即时访问站点。
最后一个非常重要的注意事项是，磁盘性能对于此功能至关重要。 由于暂停和唤醒过程涉及将大量数据写入和读取到硬盘驱动器，因此强烈建议使用快速磁盘。 固态硬盘 (SSD) 是理想之选，强烈建议使用固态硬盘，并且应确保 Windows 页面文件存储在其中（如果操作系统本身未安装在 SSD 上，请配置操作系统以将页面文件移动到其中）。
无论是否使用 SSD，我们还建议修复页面文件的大小，以便适应将页面输出数据写入其中，而无需重设文件大小。 当操作系统需要在页面文件中存储数据时，可能会进行页面文件大小重设，因为默认情况下，Windows 配置为根据需要自动调整其大小。 通过将大小设置为固定大小，可以阻止重设大小并大大提升性能。
若要配置预先固定的页面文件大小，需要计算其理想大小，具体取决于要暂停的站点数以及这些站点占用的内存量。 如果活动工作进程的平均值为 200 MB，并且服务器上有 500 个站点将暂停，则页面文件应至少比页面文件的基本大小大 (200 * 500) MB（因此本例中为基数 + 100 GB）。
注意
当站点暂停时，每个站点将消耗大约 6 MB，因此在本例中，如果所有站点都暂停，则内存使用量约为 3 GB。 但在现实中，你可能永不会同时暂停它们。
传输层安全性优化参数
使用传输层安全性 (TLS) 会增加 CPU 成本。 TLS 最昂贵的组件是建立会话的成本，因为其涉及完全握手。 重新连接、加密和解密也会增加成本。 为提升 TLS 性能，请执行以下操作：
为 TLS 会话启用 HTTP 持续连接。 这消除了会话建立成本。
在适当时重复使用会话，尤其是对于非持续连接流量。
选择性应用加密，仅对需要加密的站点页面或部分应用，而不是应用于整个站点。
注意
- 较大的密钥提供更高的安全性，但也会占用更多 CPU 时间。
- 可能并不需要加密所有组件。 但是，混合使用纯 HTTP 和 HTTPS 可能会导致弹出警告，指出页面上并非所有内容都安全。
Internet 服务器应用程序编程接口 (ISAPI)
ISAPI 应用程序不需要特殊优化参数。 如果编写专用 ISAPI 扩展，请确保编写目的是为了性能和资源使用。
托管代码优化指南
IIS 10.0 中的集成管道模型实现了高度灵活性和可扩展性。 在本机代码或托管代码中实现的自定义模块可以插入管道中，也可以替换现有模块。 尽管此扩展性模型带来了简便性，但在插入连接到全局事件的新托管模块前，应小心谨慎。 添加全局托管模块意味着所有请求（包括静态文件请求）都必须接触托管代码。 自定义模块容易受到垃圾回收等事件的影响。 此外，由于在本机代码与托管代码之间封送数据，自定义模块会增加大量 CPU 成本。 如有可能，应为托管模块将 preCondition 设置为 managedHandler。
若要获得更好的冷启动性能，请确保预编译 ASP.NET 网站或利用 IIS 应用程序初始化功能来预热应用程序。
如果不需要会话状态，请确保对每个页面都关闭。
如果有许多 I/O 绑定操作，请尝试使用相关 API 的异步版本，这将提供更佳的可伸缩性。
此外，正确使用输出缓存也会增强网站性能。
以隔离模式运行包含 ASP.NET 脚本的多个主机时（每个站点一个应用程序池），请监视内存使用情况。 确保服务器有足够的 RAM 来满足预期数量的并发运行应用程序池。 请考虑使用多个应用程序域，而不是多个独立进程。
影响 IIS 性能的其他问题
以下问题可能会影响 IIS 性能：
安装不感知缓存的筛选器
安装不感知 HTTP 缓存的筛选器会导致 IIS 完全禁用缓存，从而导致性能不佳。 在 IIS 6.0 之前编写的 ISAPI 筛选器可能会导致此行为。
通用网关接口 (CGI) 请求
出于性能原因，不建议在 IIS 中使用 CGI 应用程序为请求提供服务。 频繁创建和删除 CGI 进程会涉及大量开销。 更好的替代方法包括使用 FastCGI、ISAPI 应用程序脚本和 ASP 或 ASP.NET 脚本。 隔离适用于其中每个选项。