IIS基本设置、回收机制、性能、并发、安全性

一般把站点发布到IIS上运行正常后，不多会去考虑IIS提供的各类参数，如何配置才是最适合当前站点运行须要的？这篇文章，从基本设置、回收机制、性能、并发、安全性等IIS设置讲解应当如何优化。

 

先来“IIS应用程序池”优化后的参数配置截图：

 

图中一些数值限制参数，能够借助一些工具（如：windows性能监控）观察站点运行的指标进行设置，具体后面会介绍到

 

 

下面来分别解说下这些参数为何要这样设置（注：文章中的参数，不是按照应用程序池的设置从上到下排列的，而是按照优化的功能点排列）

 

1、设置应用程序池默认设置

 

按以下图进行默认参数模板设置，设置后，新建的应用程序池就使用这个默认参数模板。

 

2、常规设置

 

IIS版本号查看

 

在iis管理器中->帮助->关于Internet信息服务，以下图，版本是IIS10.

 

 

常规 > 启动32位应用程序

 

默认值：False

 

优化设置：按需设置。若是确认站点依赖一些32位的组件，需将此设置为true。

 

建议：为 32bit 应用程序的网站单首创建一个应用程序池

 

参考：64位系统上iis运行32位的网站程序

 

常规 > 托管管道模式

 

IIS7 应用程序池新增的经典模式和集成模式

 

经典模式：是为了保留和IIS6同样的处理方式，之前开发的代码，能够方便的移植到IIS7上。

 

集成模式：将ASP.NET请求管道与IIS核心管道组合在一块儿，这种模式与操做系统结合更紧密，可以提供更好的性能，可以实现配置和治理的模块化，并且增长了使用托管代码模块扩展IIS时的灵活性。

 

优化设置： 改成 Integrated（集成模式）

 

参考：对IIS7经典模式和集成模式的理解

 

3、 优化回收策略

 

回收 > 固定时间间隔（分钟）

 

一个时间段，超过该时间段，应用程序池将回收。值为 0 ，则应用程序池不会按固定间隔回收

 

默认值：1740分钟，29小时

 

优化设置：改成0 。由于没法避免在高峰期发生回收。同时设置“回收 > 特定时间”

 

回收 > 特定时间

 

应用程序池进行回收的一组特定的本地时间（24小时制）

 

优化设置：固定在低峰期时回收。eg：设定为 04:00 、15:30 等

 

另外，也可使用windows计划任务实现iis站点每周六晚定时回收

 

进程模型 > 闲置超时（分钟）

 

一个时间段，设定工做进程容许保持闲置状态的最大时间间隔，超过该时间就会自动关闭。

 

优化设置：改成0，避免内存信息频繁被回收清空。同时设置“回收 > 特定时间”

 

进程模型 > 空闲超时操做

 

默认是“Terminate”（另外一个选项是“Suspend”）。

 

Terminate 表示一旦超时就终止服务，并回收工做进程的缓冲区的内存；

 

Suspend 则悬停等待，暂不回收缓冲区内存。

 

另外：

 

CPU超限占用安全方案设置

 

CPU限制并非用于控制每一个进程的CPU利用率，而是一种处理发生CPU超限的工做进程的安全方案，这样能够避免工做进程占用CPU太久。

 

参考：iis7.0 cpu 限制

 

iis中对cpu限制的操做：

 

1.限制：10000 （以百分比*1000计算，10000则表示10%）

 

2.限制操做：一、noaction 无操做 二、KillW3wp 删除进程 并在限制时间内从新开启新进程

 

3.限制间隔（分钟）：设置时间限制，多久时间内重启和检测

 

内存超限回收机制

 

根据实际运行状况设定 "回收 > 虚拟内存限制" 和 "回收 > 专用内存限制"，默认为禁用状态，通常不用为此专门设定。

 

开启|关闭时间限制

 

根据实际运行状况设定，默认90秒。如上图，我都设置为了120秒

 

进程模型 > 关闭时间限制（秒）：为工做进程指定的，完成处理请求并关闭的时间段。若是工做进程超过关闭时间限制，将被终止。

 

进程模型 > 启动时间限制（秒）：为工做进程指定的，启动并进行初始化的时间段。若是工做进程初始化时间超过启动时间限制，将被终止。

 

回收 > 禁用重叠回收

 

默认值 false。应用程序池使用重叠回收方式。在这种方式下，当应用程序池要关闭某个工做进程时，会先建立一个工做进程，直到新的工做进程成功建立后才关闭旧的工做进程； 

 

设置为 true，则先关闭旧的工做进程，而后再建立新的工做进程。 若是Web 应用程序不支持多实例运行，那么你必须配置应用程序池禁止使用重叠回收方式。

 

回收 > 生成回收事件条目

 

IIS事件查看器

 

方法一：点击“开始→运行”，输入eventvwr，点击“肯定”，就能够打开事件查看器。

 

方法二：单击“开始”-“设置”-“控制面板”-“管理工具”-“事件查看器”，开事件查看器窗口。

 

方法三：在“运行”对话框中手工键入“%SystemRoot%/system32/eventvwr.msc /s”打开事件查看器窗口。

 

4、性能

 

关闭IIS日志

 

当开启记录功能后，IIS会事无巨细地忠实记录全部的web访问记录。这些记录文件的内容是很是庞杂的，好比访问时间、客户端IP、从哪一个连接访问、 Cookies等，另外还包括 Method(方法), UserAgent(用户代理)等。这些记录不但占用大量的磁盘空间还大大地影响了web服务器的性能。有人作过评测，中止访问记录能够提高5%到8%的web性能。

 

启用内容过时（客户端缓存）

 

对于静态文件启用内容过时能够提升访问性能。

 

一、首先网站的目录要划分合理，图片、CSS、JavaScript均放在单独目录下

 

二、而后在IIS中选择要缓存的目录 > HTTP 响应标头 > 设置经常使用标头 > 设置"web内容过时"策略

 

如上图webDemo站点，这样，用户浏览器将比较当前日期和截止日期，以便决定是显示缓存页仍是从服务器请求更新的页，因为图片、CSS、JS一般变化较少，所以基本上都从本地缓存读取，从而加快显示速度。

 

参考：IIS7禁用单个静态文件的客户端缓存

 

服务器验证缓存

 

IIS自动机制，会在访问css、js等静态文件时，返回给浏览器Last-Modified和Etag标记

 

参考：

 

浏览器缓存之Last-Modified

 

服务端的缓存验证 Last-Modified和Etag

 

启用Gzip压缩

 

IIS 压缩功能使用Gzip算法

 

gzip是HTTP的一种压缩算法，HTTP压缩是在Web服务器和浏览器间传输压缩文本内容的方法。HTTP压缩采用通用的压缩算法如gzip等压缩HTML、JavaScript或 CSS文件。压缩的最大好处就是下降了网络传输的数据量，从而提升客户端浏览器的访问速度。固然，同时也会增长一点点服务器的负担。Gzip是比较常见的一种HTTP压缩算法。

 

5、IIS初始化（预加载），解决（被回收后）第一次访问慢

 

参考：https://www.cnblogs.com/teamblog/p/6195078.html

 

设置以后，何时会自动初始化？

 

（好比初始化执行 Global.Application_Start 初始化函数）

 

1)会 - 应用程序池启动、应用程序池回收、cmd->iisreset （w3wp的PID会变）

 

2)不会 - 站点重启（IIS站点右键 > 管理网站 > 从新启动）、站点启动

 

3)不会 - web.config更改引发的应用程序池回收

 

在IIS10版本上测试是上面行为。另外有人IIS8.5上使用也是一样的行为，参考文章。

 

步骤1、安装IIS应用程序初始化功能

 

步骤2、设置IIS上应用程序池启动模式

 

常规 > 启动模式

 

默认值：OnDemand（按需运行模式），另外值AlwaysRuning（始终运行模式）

 

优化设置：改成 AlwaysRunning（始终运行）

 

步骤3、设置站点预加载

 

在IIS上站点右键 > 管理网站 > 高级设置，把【预加载已启用】设置为true。

 

 

 

 

步骤4、配置站点 web.config ，添加站点重启后预加载请求的页面

地址：http://webdemo.com/home/about

 

这样操做保存后，IIS会修改 web.config 添加以下内容

 

<system.webServer>
    …… 
    <applicationInitialization doAppInitAfterRestart="true">
        <add initializationPage="home/about" hostName="" />
    </applicationInitialization>
</system.webServer>

 

 

若是只是初始化（好比只执行 Global.Application_Start 初始化函数），不须要访问特定API进行额外资源的初始化，则不须要 <add initializationPage="**" /> 子节点

 

6、并发性

 

常规 > 队列长度

 

HTTP.sys 将针对应用程序池排队的最大请求数。默认值1000，最大值65535。

 

若是设置太大则会消耗大量的系统资源 ，而设置过小会致使客户端访问时频繁出现"503服务不可用"响应。

 

优化设置：可先改成 5000（设置为预期最多并发用户数的1.5倍，官方参考:https://docs.microsoft.com/zh-cn/previous-versions/office/communications-server/dd441171(v=office.13)

 

使用windows性能监控（性能监控：cmd->perfmon.msc），添加“HTTP Service Request Queues/CurrentQueueSize”指标，观察某个应用程序池当前队列中请求的个数。

 

启用Web园（Web Garden），进程模型 > 最大工做进程数

 

在Web园中你能够配置此应用程序池所使用的最大工做进程数，默认为1，最大能够设置为4000000； 配置使用多个工做进程能够提升该应用程序池处理请求的性能，可是在设置为使用多个工做进程以前，请考虑如下两点： 

 

一、每个工做进程都会消耗系统资源和CPU占用率；太多的工做进程会致使系统资源和CPU利用率的急剧消耗； 

 

二、每个工做进程都具备本身的状态数据，若是Web应用程序依赖于工做进程保存状态数据，那么可能不支持使用多个工做进程。 

 

这样设置，增长了处理进程数，至关于集群，避免大量请求处于排队状态

 

参考：IIS并发优化 (https://www.jianshu.com/p/5de10f1a994e)

 

文章介绍：使用windows性能监控：cmd->perfmon.msc。监控IIS应用运行状况，再根据须要进行iis参数设置

Web Service/Current Connections 监控某个应用程序池来指示当前该应用程序池的链接的数量。

 

ASP.NET Apps v4.0.30319/Requests Executing 监控全部的 ASP.Net 4.0 正在处理中的请求数量。

 

ASP.NET v4.0.30319/Requests Current 与上述相似用于监控 Asp.Net 4.0 正在处理中的请求数量。

 

HTTP Service Request Queues/CurrentQueueSize 用来监控某个应用程序池当前队列中请求的个数。

 

调整支持并发请求的数量

 

默认支持并发请求数量为：5000

 

超出此并发数，会报异常

 

HTTP Error 503.2 - Service Unavailable

 

The serverRuntime@appConcurrentRequestLimit setting is being exceeded.

 

参考：IIS 并发请求设置如何设置？

 

站点最大并发链接数

 

右键站点 > 高级设置 > 限制 > 最大并发链接数

 

 

设置站点线程数：minWorkerThreads、maxWorkerThreads、maxIoThreads

 

（感谢园友 @ runliuv 提供的新姿式）

 

minWorkerThreads默认1，maxWorkerThreads默认20，maxIoThreads默认20

 

一、配置文件：C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config

 

二、修改参数： <processModel autoConfig="false" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" />

 

其中：minWorkerThreads = maxWorkerThreads / 2

 

参数具体值如何设置，还须要各自对站点进行压力测试中调整

 

参考：

 

IIS7.5优化--提升线程数来适应高并发https://www.cnblogs.com/lpyicq/p/7852298.html

 

processModel 元素（ASP.NET 设置架构）

 

Improving ASP.NET Performance    （微软文档中给出了推荐值，以下图）

 

 

 

 

7、安全性

 

为不一样工做进程指定应用程序池（工做进程隔离模式）

 

一台服务器上有很是多的Web站点。如何才能作到各个站点之间相互独立，不因某些Web站点出现故障而影响其余站点呢?--为不一样工做进程指定应用程序池是个很好的解决办法。

 

进程模型 > 标识，使用ApplicationPoolIdentity虚拟帐户

 

ApplicationPoolIdentity – 默认状况下，选择“应用程序池标识”账户。启动应用程序池时动态建立“应用程序池标识”账户，所以，此账户对于您的应用程序来讲是最安全的。（这样，每一个应用程序池都有各自的帐户，就避免了木立刻传到其中一个池下站点，会对另外一个池的文件夹有操做权限）

 

参考：IIS7.5中神秘的ApplicationPoolIdentity

 

启用快速失败保护

 

 

 

若是Web应用程序代码编写有问题，它可能会致使工做进程持续出现问题。默认状况下应用程序池配置为启用快速失败保护，当工做进程在配置的时间段（默认为5分钟）内发生的失败次数超过了配置的值（默认为5次），则禁用此应用程序池。