Internet Information Services （IIS） 10.0 包含在 Windows Server 2022 中。 它使用类似于 IIS 8.5 和 IIS 7.0 的进程模型。 内核模式 Web 驱动程序 （http.sys） 接收和路由 HTTP 请求，并满足来自其响应缓存的请求。 工作进程注册 URL 子空间，http.sys 将请求路由到相应的进程（或应用程序池的进程集）。
HTTP.sys 负责连接管理和请求处理。 该请求可以从 HTTP.sys 缓存中提供，也可以传递给 worker 进程进行进一步处理。 可以配置多个工作进程，从而以更低的成本提供隔离。 有关请求处理工作原理的更多信息，请参阅下图：
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 缓存由 Scave 程序定期扫描，并删除在 Scavenger 扫描之间未访问的条目。 将 scavenger period 设置为较高的值会减少 scavenger 扫描的次数。 但是，缓存内存使用量可能会增加，因为较旧、访问频率较低的条目可以保留在缓存中。 将时间段设置得太低会导致更频繁的清道夫扫描，并可能导致过多的刷新和缓存改动。
请求和连接管理设置
在 Windows Server 2022 中，HTTP.sys 会自动管理连接。 以下注册表设置不再使用：
最大连接数
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 线程管理器会尽最大努力根据 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/缓存
| 特征 | DESCRIPTION | 违约 |
|---|---|---|
| 已启用 | 设置为 False 时禁用用户模式 IIS 缓存。 当缓存命中率非常小时，您可以完全禁用缓存，以避免与缓存代码路径关联的开销。 禁用用户模式缓存不会禁用内核模式缓存。 | 真 实 |
| enableKernelCache | 设置为 False 时禁用内核模式缓存。 | 真 实 |
| 最大缓存大小 | 将 IIS 用户模式缓存大小限制为指定的大小（以 MB 为单位）。 IIS 根据可用内存调整默认值。 根据经常访问的文件集的大小与 RAM 或 IIS 进程地址空间的大小，仔细选择该值。 | 0 |
| 最大响应大小 | 缓存指定大小的文件。 实际值取决于数据集中最大文件的数量和大小与可用 RAM 的对比。 缓存经常请求的大型文件可以减少 CPU 使用率、磁盘访问和相关的延迟。 | 262144 |
压缩行为设置
默认情况下，从 7.0 开始的 IIS 会压缩静态内容。 此外，在安装 DynamicCompressionModule 时，默认情况下会启用动态内容的压缩。 压缩会降低带宽使用率，但会增加 CPU 使用率。 如果可能，压缩内容将缓存在内核模式缓存中。 从 8.5 开始，IIS 允许独立控制静态和动态内容的压缩。 静态内容通常是指不变的内容，例如 GIF 或 HTM 文件。 动态内容通常由服务器上的脚本或代码（即 ASP.NET 页）生成。 您可以将任何特定扩展的分类自定义为 static 或 dynamic。
要完全禁用压缩，请从 applicationHost.config的 system.webServer/globalModules 部分的模块列表中删除 StaticCompressionModule 和 DynamicCompressionModule 。
system.webServer/httpCompression
| 特征 | DESCRIPTION | 违约 |
|---|---|---|
| staticCompression-EnableCpuUsage staticCompression-DisableCpuUsage dynamicCompression-EnableCpuUsage dynamicCompression-DisableCpuUsage |
如果当前 CPU 使用率百分比高于或低于指定限制，则启用或禁用压缩。 从 IIS 7.0 开始，如果稳态 CPU 增加到超过禁用阈值，则会自动禁用压缩。 如果 CPU 降至启用阈值以下，则启用压缩。 |
分别为 50、100、50 和 90 |
| 目录 | 指定临时存储和缓存静态文件的压缩版本的目录。 如果经常访问此目录，请考虑将此目录从系统驱动器中移出。 | %SystemDrive%\inetpub\temp\IIS 临时压缩文件 |
| doDiskSpaceLimiting | 指定所有压缩文件可以占用的磁盘空间量是否存在限制。 压缩文件存储在由 directory 属性指定的压缩目录中。 | 真 实 |
| maxDiskSpaceUsage | 指定压缩文件在压缩目录中可以占用的磁盘空间字节数。 如果所有压缩内容的总大小太大，则可能需要增加此设置。 |
100 MB |
system.webServer/url压缩
| 特征 | DESCRIPTION | 违约 |
|---|---|---|
| doStaticCompression 压缩 | 指定是否压缩静态内容。 | 真 实 |
| doDynamicCompression 压缩 | 指定是否压缩动态内容。 | 真 实 |
注释
对于运行 IIS 10.0 且平均 CPU 使用率较低的服务器，请考虑为动态内容启用压缩，尤其是在响应较大时。 这应首先在测试环境中完成，以评估基准对 CPU 使用率的影响。
调整默认文档列表
默认 document 模块处理对目录根目录的 HTTP 请求，并将其转换为对特定文件（如 Default.htm 或 Index.htm）的请求。 平均而言，Internet 上大约 25% 的请求通过默认文档路径。 这因各个站点而异。 当 HTTP 请求未指定文件名时，默认文档模块会在文件系统中搜索允许的默认文档列表中的每个名称。 这可能会对性能产生负面影响，尤其是在访问内容需要进行网络往返或接触磁盘时。
您可以通过选择性地禁用默认文档以及减少文档列表或对文档列表进行排序来避免开销。 对于使用默认文档的网站，您应该将列表减少到仅使用的默认文档类型。 此外，对列表进行排序，使其以最常访问的默认文档文件名开头。
您可以通过在 applicationHost.config 中自定义 location 标记内的配置，或者通过在内容目录中直接插入 web.config 文件，有选择地设置特定 URL 上的默认文档行为。 这允许使用混合方法，该方法仅在必要时启用默认文档，并将列表设置为每个 URL 的正确文件名。
要完全禁用默认文档，请从 applicationHost.config的 system.webServer/globalModules 部分的模块列表中删除 DefaultDocumentModule。
system.webServer/defaultDocument
| 特征 | DESCRIPTION | 违约 |
|---|---|---|
| 启用 | 指定启用默认文档。 | 真 实 |
<files> 元素 |
指定配置为默认文档的文件名。 | 默认列表为 Default.htm、 Default.asp、 Index.htm、 Index.html、 Iisstart.htm和 Default.aspx 。 |
中央二进制日志记录
当服务器会话下有许多 URL 组时，为各个 URL 组创建数百个格式化日志文件并将日志数据写入磁盘的过程可能会快速消耗宝贵的 CPU 和内存资源，从而产生性能和可伸缩性问题。 集中式二进制日志记录可最大限度地减少用于日志记录的系统资源量，同时为需要它的组织提供详细的日志数据。 解析二进制格式的日志需要后处理工具。
您可以通过将 centralLogFileMode 属性设置为 CentralBinary 并将 enabled 属性设置为 True 来启用中央二进制日志记录。 考虑将中央日志文件的位置从系统分区移动到专用日志记录驱动器上，以避免系统活动和日志记录活动之间发生争用。
system.applicationHost/日志
| 特征 | DESCRIPTION | 违约 |
|---|---|---|
| centralLogFileMode | 指定服务器的日志记录模式。 将此值更改为 CentralBinary 以启用中央二进制日志记录。 | 网站 |
system.applicationHost/log/centralBinaryLogFile
| 特征 | DESCRIPTION | 违约 |
|---|---|---|
| 启用 | 指定是否启用中央二进制日志记录。 | 假 |
| 目录 | 指定写入日志条目的目录。 | %SystemDrive%\inetpub\logs\LogFiles |
应用程序和站点优化
以下设置与应用程序池和站点调整相关。
system.applicationHost/applicationPools/applicationPoolDefaults
| 特征 | DESCRIPTION | 违约 |
|---|---|---|
| queueLength | 指示 HTTP.sys 在将来的请求被拒绝之前，应用程序池排队的请求数。 当超出此属性的值时，IIS 将拒绝后续请求，并显示 503 错误。 如果观察到 503 错误，请考虑为与高延迟后端数据存储通信的应用程序增加此值。 |
1000 |
| enable32BitAppOnWin64 | 如果为 True，则允许 32 位应用程序在具有 64 位处理器的计算机上运行。 如果担心内存消耗，请考虑启用 32 位模式。 由于指针大小和指令大小较小，因此 32 位应用程序使用的内存比 64 位应用程序少。 在 64 位计算机上运行 32 位应用程序的缺点是用户模式地址空间限制为 4 GB。 |
假 |
system.applicationHost/sites/VirtualDirectoryDefault
| 特征 | DESCRIPTION | 违约 |
|---|---|---|
| allowSubDirConfig 的 | 指定 IIS 是在低于当前级别的内容目录中查找 web.config 文件 （True），还是不在低于当前级别的内容目录中查找 web.config 文件 （False）。 通过施加一个简单的限制，只允许在虚拟目录中进行配置，IIS 10.0 可以知道，除非 /<name>.htm 是一个虚拟目录，否则它不应该查找配置文件。 跳过其他文件作可以显著提高具有大量随机访问的静态内容的网站的性能。 | 真 实 |
管理 IIS 10.0 模块
IIS 10.0 已分解为多个用户可扩展的模块，以支持模块化结构。 这种因式分解的成本很小。 对于每个模块，集成管道必须为与该模块相关的每个事件调用该模块。 无论模块是否必须执行任何工作，都会发生这种情况。 您可以通过删除与特定网站无关的所有模块来节省 CPU 周期和内存。
针对简单静态文件优化的 Web 服务器可能仅包含以下五个模块：UriCacheModule、HttpCacheModule、StaticFileModule、AnonymousAuthenticationModule 和 HttpLoggingModule。
要从 applicationHost.config中删除模块，除了删除 system.webServer/globalModules 中的模块声明外，还要从 system.webServer/handlers 和 system.webServer/modules 部分中删除对模块的所有引用。
传统 ASP 设置
处理经典 ASP 请求的主要成本包括初始化脚本引擎、将请求的 ASP 脚本编译为 ASP 模板以及在脚本引擎上执行模板。 虽然模板执行成本取决于请求的 ASP 脚本的复杂性，但 IIS 经典 ASP 模块可以在内存中缓存脚本引擎，并在内存和磁盘中缓存模板（仅当内存中模板缓存溢出时），以提高 CPU 密集型方案中的性能。
以下设置用于配置经典 ASP 模板缓存和脚本引擎缓存，它们不会影响 ASP.NET 设置。
system.webServer/asp/缓存
| 特征 | DESCRIPTION | 违约 |
|---|---|---|
| diskTemplateCache目录 | 当内存中高速缓存溢出时，ASP 用于存储已编译模板的目录的名称。 建议：设置为不经常使用的目录，例如，不与作系统共享的驱动器、IIS 日志或其他经常访问的内容。 |
%SystemDrive%\inetpub\temp\ASP 编译模板 |
| maxDiskTemplateCacheFiles 文件 | 指定可在磁盘上缓存的已编译 ASP 模板的最大数量。 建议：设置为最大值 0x7FFFFFFF。 |
2000 |
| scriptFileCacheSize | 此属性指定可在内存中缓存的已编译 ASP 模板的最大数量。 建议：设置为至少与应用程序池提供的经常请求的 ASP 脚本的数量一样多。 如果可能，请设置为内存限制允许的任意数量的 ASP 模板。 |
500 |
| scriptEngineCacheMax | 指定将在内存中保持缓存的脚本引擎的最大数量。 建议：设置为至少与应用程序池提供的经常请求的 ASP 脚本的数量一样多。 如果可能，请设置为内存限制允许的任意数量的脚本引擎。 |
250 |
system.webServer/asp/limits
| 特征 | DESCRIPTION | 违约 |
|---|---|---|
| 处理器ThreadMax | 指定 ASP 可以创建的每个处理器的最大工作线程数。 如果当前设置不足以处理负载，则增加，这可能会导致在处理请求时出现错误或导致 CPU 资源使用不足。 | 二十五 |
system.webServer/asp/comPlus
| 特征 | DESCRIPTION | 违约 |
|---|---|---|
| executeInMta | 如果在 IIS 提供 ASP 内容时检测到错误或故障，则设置为 True 。 例如，当托管多个独立站点时，每个站点都在自己的工作进程下运行时，可能会发生这种情况。 错误通常从事件查看器中的 COM+ 报告。 此设置在 ASP 中启用多线程单元模型。 | 假 |
ASP.NET 并发设置
ASP.NET 3.5
默认情况下，ASP.NET 限制请求并发性以减少服务器上的稳态内存消耗。 高并发应用程序可能需要调整一些设置以提高整体性能。 您可以在 aspnet.config 文件中更改此设置：
<system.web>
<applicationPool maxConcurrentRequestsPerCPU="5000"/>
</system.web>
以下设置对于充分利用系统上的资源非常有用：
maxConcurrentRequestPerCpu 默认值：5000
此设置限制系统上并发执行的 ASP.NET 请求的最大数量。 默认值为 conservative 以减少 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
| 特征 | DESCRIPTION | 违约 |
|---|---|---|
| 记忆 | 如果虚拟内存消耗超过指定的限制（以 KB 为单位），则启用进程回收。 对于具有 2 GB 小地址空间的 32 位计算机，这是一个有用的设置。 它可以帮助避免由于内存不足错误而导致请求失败。 | 0 |
| privateMemory （私有内存） | 如果私有内存分配超过指定的限制（以 KB 为单位），则启用进程回收。 | 0 |
| 请求 | 在一定数量的请求后启用进程回收。 | 0 |
| 时间 | 在指定时间段后启用流程回收。 | 29:00:00 |
动态工作进程分页调优
从 Windows Server 2012 R2 开始，IIS 提供了将工作进程配置为在空闲一段时间后挂起的选项（除了自 IIS 7 以来就存在的终止选项）。
idle worker process page-out 和 idle worker process termination 功能的主要目的是节省服务器上的内存利用率，因为即使站点只是坐在那里侦听，也会消耗大量内存。 根据网站上使用的技术（静态内容 vs ASP.NET 与其他框架），使用的内存可以从大约 10 MB 到数百 MB 不等，这意味着如果您的服务器配置了许多站点，则找出最有效的站点设置可以显著提高活动站点和暂停站点的性能。
在讨论细节之前，我们必须记住，如果没有内存限制，那么最好简单地将站点设置为永不暂停或终止。 毕竟，如果 worker 进程是机器上唯一的进程，那么终止它几乎没有价值。
注释
如果站点运行不稳定的代码，例如具有内存泄漏的代码或其他不稳定的代码，则将站点设置为在空闲时终止可能是修复代码错误的快速而肮脏的替代方法。 我们不鼓励这样做，但在紧要关头，最好在更持久的解决方案正在制定中时将此功能用作清理机制。
另一个需要考虑的因素是，如果站点确实使用了大量内存，则暂停进程本身会造成损失，因为计算机必须将工作进程使用的数据写入磁盘。 如果 worker 进程正在使用大量内存，则暂停它可能比必须等待它启动备份的成本更高。
为了充分利用工作进程暂停功能，您需要查看每个应用程序池中的站点，并决定哪些应该暂停，哪些应该终止，哪些应该无限期处于活动状态。 对于每个作和每个站点，您需要找出理想的超时时间。
理想情况下，您将配置为暂停或终止的网站是那些每天都有访问者的网站，但不足以保证它始终保持活动状态。 这些网站通常是每天有大约 20 名独立访问者或更少的网站。 您可以使用网站的日志文件分析流量模式并计算平均每日流量。
请记住，一旦特定用户连接到该网站，他们通常会在该网站上停留至少一段时间，并发出额外的请求，因此仅计算每日请求可能无法准确反映真实的流量模式。 为了获得更准确的读数，您还可以使用 Microsoft Excel 等工具来计算请求之间的平均时间。 例如：
| 编号 | 请求的 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 | / 来源SilverLight/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（在本例中为 base + 100 GB）。
注释
当站点被暂停时，每个站点将消耗大约 6 MB，因此在我们的例子中，如果所有站点都被暂停，内存使用量将约为 3 GB。 但实际上，您可能永远不会同时暂停所有 ID。
传输层安全性调优参数
使用传输层安全性 （TLS） 会带来额外的 CPU 成本。 TLS 最昂贵的组成部分是建立会话建立的成本，因为它涉及完全握手。 重新连接、加密和解密也会增加成本。 为了获得更好的 TLS 性能，请执行以下作：
为 TLS 会话启用 HTTP keep-alive。 这消除了会话建立成本。
在适当的时候重用会话，尤其是对于非保持活动流量。
有选择地仅将加密应用于需要加密的页面或网站部分，而不是整个网站。
注释
- 较大的密钥提供更高的安全性，但也使用更多的 CPU 时间。
- 可能不需要加密所有组件。 但是，混合使用普通 HTTP 和 HTTPS 可能会导致弹出警告，指出并非页面上的所有内容都是安全的。
Internet 服务器应用程序编程接口 （ISAPI）
ISAPI 应用程序不需要特殊的优化参数。 如果您编写私有 ISAPI 扩展，请确保它是为性能和资源使用而编写的。
托管代码优化准则
IIS 10.0 中的集成管道模型可实现高度的灵活性和可扩展性。 在本机代码或托管代码中实现的自定义模块可以插入到管道中，也可以替换现有模块。 尽管此扩展性模型提供了便利和简单性，但在插入挂接到全局事件的新托管模块之前，您应该小心。 添加全局托管模块意味着所有请求（包括静态文件请求）都必须接触托管代码。 自定义模块容易受到垃圾回收等事件的影响。 此外，由于在本机代码和托管代码之间封送数据，自定义模块会显著增加 CPU 成本。 如果可能，您应该将 managedModule 的 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 脚本。 隔离可用于这些选项中的每一个。