IIS配置
IIS无故自动关闭停止已经不是罕见的事情了，处理这个问题是让我很头痛的事情，遇到这个问题不太可能一次性解决，多数都是用排除法一个个测试排除错误，最终找到那个错误命令。最近我的服务器遇到了这个问题，我很无奈，我很急，客户也很着急，每天ＩＩＳ都要自动停止２次以上，我总是怀疑是进程池问题，此文章是针对ＩＩＳ进程池解决办法，如果你遇到了死循环代码，或者其他非进程池，那此文章不太适合你了
网络上有关iis的问题和相关解决方案，多不胜搜，但很多都比较零散，没有系统的解决方案；另外，有些解决方法，似是而非，不能找到其中的问题关键点，本人平时对于服务器的应用上也有点实践，因此，今天稍稍总结一点平时遇到地问题和解决方法，特别是对iis的特殊权限引起问题、iis应用程序池假死问题和比较罕见的iis重启命令和自动重启办法。其它相关问题，继续关注本博。
一、2003应用程序池自动死了，不能恢复了，一直出现 Service Unavailable 常见方法如下。
1：没有打SP1补丁的时候会出现这个IIS6.0假死问题，但现在微软都在自动更新里面出补丁了，一般你打好最新补丁后是不会出现此问题了。（所以现在的IIS假死与这个关系不是很大）
2：从IIS6.0开始CPU资源都在应用池里面限制了，不象以前的IIS.5。所以假死的池的缘故就是池被拉死，你在网站打不开的时候可以看到你的某个应用池是禁用的，上面出现一个红叉。你鼠标右键启动网站又会自动恢复。 这个原因：大概是以下几个因数造成的。
（1）：你限制了应用池的资源，限制得太小 比如：50这样或更少更多一点，这个时候如果你这个池下面的网站占用CPU太高，比如超过50% 那么5分钟后他就自动死了，手工默认建立的应用池默认是超过资源不操作。
出现上面这个情况解决方法：1：不限制CPU资源，（这个是不可取的，不限制资源，有的程序有BUG占用资源厉害了的，服务器都会被拉死，你可能都无法操作服务器。）2：在超过资源那里选择关闭，这个关闭默认是失败5次，90秒内恢复，一般默认就可。网站能自动恢复，这个关闭：不是永久关闭，意思是超过资源关闭，然后在某时间内自动恢复池。不操作就是不恢复，这个是很多人的误区。
（2）：内存限制 在IIS6.0应用池上面有虚拟内存和最大内存限制，如果你设置了这个。那么网站访问量大了 也会出现假死，所以不建议设置这里。默认就可。
3：就是服务器自身内存太小，网站运行当然需要使用到内存了，当内存不够的时候应用池也会死掉变成禁用。那么只有等内存全部释放出来才能恢复应用池了。出现这个情况：那么你就要考虑加内存或者检查到底是什么程序占用了内存了。比如MSSQL数据库，这个可是吃内存得大户啊，最好别和WEB服务器同时一个服务器上。很多人用1G内存做 2003系统，2003NET结构是很占用内存的，所以做服务器选2003还得把内存加到2G或更高才好。 内存不够上面 2点讲到的，是没办法操作了，也无法自动恢复。
4：就是ACCESS数据库太大或查询太多，这个也会出现把IIS拉死，解决方法；修复ACCESS数据库，或尽量少用ACCESS数据库，升级至sqlserver数据库；或者在技术方面革新，像现在有些网站系统，风讯、动易等cms；pjblog、zblog等博客程序，都支持生成静态功能.
5：不同网站用不同应用池：根据你自己实际情况而定，站点大的最好独立一个应用池，限制他的资源超过了自动回收，看上面（1）讲到的，这样就不影响其他站点。中型站点：多个网站共用一个应用池，比如5个站点用一个池，设置他资源时间等等。这样他们就算超资源了也不影响其他应用池的网站。
6：设置回收时间：很多人以为设置回收池越短越好，其实是错误的，每次回收当然是把内存回收回来了，但加重了一次服务器的负担，当服务器比较繁忙的时候，有可能导致其他应用池死。所以建议设置共1000就行了。其他独立池按照他网站流量而设置 可以设置600 也行，共用的不建议设置太短。
7：网站后台过不了多久自动退出又要重新登陆：这个情况就是你设置回收时间太短了，按照 6点设置吧。 不要设置什么20分、30分这样的，这样不好的。另外一个原因就是和站的响应设置时间有关，设置得稍长些。
8：windows 2003系统iis6访问本机的站点时提示“Service Unavailable”；
查看iis的应用程序池,状况提示为：未指定错误，同时应用程序池自动停止运行；
用事件查看器查看系统错误日志，发现如下提示：
-----------------------------------
应用程序-特定 权限设置未将 COM 服务器应用程序(CLSID 为
{A9E69610-B80D-11D0-B9B9-00A0C922E750}
)的 本地 激活 权限授予用户 NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20)。可以使用组件服务管理工具修改此安全权限。
解决方法，给NETWORK SERVICE 加上访问iis服务的权限，具体方法如下：
点击“开始”-“控制面板”-“管理工具”-“组件服务”-“计算机”-“我的电脑”-“DCOM”选项，
选择其下的“IIS ADMIN SERVICE”，右健选择“属性”，找到“安全”，在“启动和激活权限”中编辑“自定义”，添加帐号“NETWORK SERVICE ”，给该帐号赋予“本地启动”和“本地激活”的权限，重新启动IIS之后再访问同一站点，则一切正常。
9：重启IIS中的特定应用程序池命令和自动重启的方法
在操作系统是Windows server 2003 SP1+的情况下，可以用以下命令部分重启IIS应用程序池：
cscript.exe c:\windows\system32\iisapp.vbs /a "DefaultAppPool"
其中/a 代表alternatively，"DefaultAppPool"代表应用程序池的实例名。如果要设置自动重启这个应用程序池，可以尝试放在批处理中，用计划任务调用此批处理即可。很多人觉得计划任务不安全，都要禁掉，事实上，计划任务的不安全是建立在其它方面不安全的前提上的，如果由于其它方面的不安全，被放入执行程序，计划任务执行，这和计划任务没有直接关系。当然，关掉，是会减少一些安全隐患，这是不错。
代码写的有问题，会很容易出现内存泄露的问题。
应用如果是部署在docker容器里面的，可以限制这个应用的内存。
那么，如果是传统的.NET Framework应用，部署在IIS上面呢？
老黄曾经遇到过在一台服务器上面，IIS部署了五六个站点。
其中一个站点，占用了 5、6G 的内存，然而服务器只有8G的内存，甚至胡时候会把其他一两个站点的应用程序池逼停了。
想想就可怕，资源的隔离没有做好，导致其他应用也受到了影响。
其实对IIS来说，还是可以对站点做限制的。
如何处理
应用程序池中，有两个关于内存的配置：
- 虚拟内存限制(KB)
- 专用内存限制(KB)
虚拟内存限制指的是，工作进程可以使用的最大虚拟内存量，超过这个内存量就会导致应用程序池回收。默认值是0，表示不限制。
专用内存限制指的是，工作进程可以使用的最大专用内存量，超过这个内存量就会导致应用程序池回收。默认值是0，表示不限制。
正常来说，我们常说的，应用占用了多少内存其实说的就是这个专用内存。
我们打开的任务管理器，上面看到的内存，也是专用工作集。
所以针对这上面说的情况，我们只要限制这个程序池的专用内存限制即可。
好比说限制为100MB，就把专用内存限制填102400。
当应用的内存达到这个限制的时候，它会重新拉起一个进程，然后把老的进程kill掉。
可以通过事件查看器捕获到对应的事件。
这样就可以在一定程度上缓解多个应用之间互相影响。
当然最终的解决办法还是要把内存泄露的bug处理掉。
IIS应用程序池配置详解及优化
队列长度HTTP.sys将针对应用程序池排队的最大请求数。名称应用程序池名称是应用程序池的唯一标识符。启动模式将
... 展开参数说明
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 tsd.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.常规设置
-
队列长度： 默认值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_MACHINESystemCurrentControlSetServicesHttpParameters
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_MACHINESystemCurrentControlSetServicesInetInfoParametersThreadPoolUseIdealCpu
启用此功能后，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.更多详细设置，请参考微软官方文档。
IIS的应用程序池，程序异常停用，可能的原因
1 iis中应用已停止
2 右键 项目–高级设置
3 默认内存限制，设置为 0，即没有限制，遵循应用程序的自动回收机制。如果设置内存限制1024M，就是当应用内存达到1024M时，启动内城回收机制。
4 在程序进行回收时，进程将不响应。会触发程序不响应多久后终止进程，这个时间可以设置的大一点。
5 程序故障间隔，和故障时间限制。故障上限达到后也会终止进程，可以设置单位时间的故障数量大一点。
6 设置程序启动，观察是否还会有异常终止问题。
