编辑推荐: |
本文主要讲解了IIS应用程序池配置详解及优化等相关内容。
本文来自于博客园,由火龙果Linda编辑推荐。 |
|
参数说明
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 201
HKEY_LOCAL_MACHINE\System\Current ControlSet\Services\InetInfo\ Parameters\ThreadPoolUseIdealCpu
|
6 开始,IIS 10.0 支持其线程池线程的自动理想 CPU 分配,以提高
NUMA 硬件的性能和可伸缩性。 此功能在默认情况下处于启用状态,可通过以下注册表项进行配置:
启用此功能后,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 max ConcurrentRequestsPerCPU="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 脚本。 每个选项都提供隔离。
注意:
所有设置更改完毕,需要重启IIS。 |