目录
一, 设置应用程序池默认设置...2
二, 常规设置...3
三, 优化回收策略...5
四, 性能...8
五, IIS 初始化 (预加载), 解决(被回收后) 第一次访问慢...9
六, 并发性...11
七, 安全性...12
通常把站点发布到 IIS 上运行正常后, 很少会去考虑 IIS 提供的各种参数, 如何配置才是最适合当前站点运行需要的? 这篇文章, 从基本设置, 回收机制, 性能, 并发, 安全性等 IIS 设置讲解应当如何优化.
先来 "IIS 应用程序池" 优化后的参数配置截图:
图中一些数值限制参数, 可以借助一些工具 (如: Windows 性能监控) 观察站点运行的指标进行设置, 具体后面会介绍到
下面来分别解说下这些参数为什么要这样设置(注: 文章中的参数, 不是按照应用程序池的设置从上到下排列的, 而是按照优化的功能点排列)
一,
设置应用程序池默认设置
按如下图进行默认参数模板设置, 设置后, 新建的应用程序池就使用这个默认参数模板.
二, 常规设置
IIS 版本号查看
在 iis 管理器中 ->帮助 ->关于 Internet 信息服务, 如下图, 版本是 IIS10.
常规>启动 32 位应用程序
默认值: False
优化设置: 按需设置. 如果确认站点依赖一些 32 位的组件, 需将此设置为 true.
建议: 为 32bit 应用程序的网站单独创建一个应用程序池
参考:
64 位系统上 iis 运行 32 位的网站程序
常规>托管管道模式
IIS7 应用程序池新增的经典模式和集成模式
经典模式: 是为了保留和 IIS6 一样的处理方式, 以前开发的代码, 可以方便的移植到 IIS7 上.
集成模式: 将 ASP.NET 请求管道与 IIS 核心管道组合在一起, 这种模式与操作系统结合更紧密, 能够提供更好的性能, 能够实现配置和治理的模块化, 而且增加了使用托管代码模块扩展 IIS 时的灵活性.
优化设置: 改为 Integrated(集成模式)
参考:
对 IIS7 经典模式和集成模式的理解
三, 优化回收策略
回收>固定时间间隔(分钟)
一个时间段, 超过该时间段, 应用程序池将回收. 值为 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. 限制操作: 1,noaction 无操作 2,KillW3wp 删除进程 并在限制时间内重新开启新进程
3. 限制间隔(分钟): 设置时间限制, 多久时间内重启和检测
内存超限回收机制
根据实际运行情况设定 "回收>虚拟内存限制" 和 "回收>专用内存限制", 默认为禁用状态, 一般不用为此专门设定.
开启 | 关闭时间限制
根据实际运行情况设定, 默认 90 秒. 如上图, 我都设置为了 120 秒
进程模型>关闭时间限制(秒): 为工作进程指定的, 完成处理请求并关闭的时间段. 如果工作进程超过关闭时间限制, 将被终止.
进程模型>启动时间限制(秒): 为工作进程指定的, 启动并进行初始化的时间段. 如果工作进程初始化时间超过启动时间限制, 将被终止.
回收>禁用重叠回收
默认值 false. 应用程序池使用重叠回收方式. 在这种方式下, 当应用程序池要关闭某个工作进程时, 会先创建一个工作进程, 直到新的工作进程成功创建后才关闭旧的工作进程;
设置为 true, 则先关闭旧的工作进程, 然后再创建新的工作进程. 如果 web 应用程序不支持多实例运行, 那么你必须配置应用程序池禁止使用重叠回收方式.
回收>生成回收事件条目
IIS 事件查看器
方法一: 点击 "开始→运行", 输入 eventvwr, 点击 "确定", 就可以打开事件查看器.
方法二: 单击 "开始"-"设置"-"控制面板"-"管理工具"-"事件查看器", 开事件查看器窗口.
方法三: 在 "运行" 对话框中手工键入 "%SystemRoot%/system32/eventvwr.msc /s" 打开事件查看器窗口.
四, 性能
关闭 IIS 日志
当开启记录功能后, IIS 会事无巨细地忠实记录所有的 Web 访问记录. 这些记录文件的内容是非常庞杂的, 比如访问时间, 客户端 IP, 从哪个链接访问, Cookies 等, 另外还包括 Method(方法), UserAgent(用户代理)等. 这些记录不但占用大量的磁盘空间还大大地影响了 Web 服务器的性能. 有人做过评测, 停止访问记录可以提升 5% 到 8% 的 Web 性能.
启用内容过期(客户端缓存)
对于静态文件启用内容过期可以提高访问性能.
1. 首先网站的目录要划分合理, 图片, CSS,JavaScript 均放在单独目录下
2. 然后在 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 压缩算法.
五, 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 上使用也是同样的行为, 参考文章.
步骤一, 安装 IIS 应用程序初始化功能
步骤二, 设置 IIS 上应用程序池启动模式
常规>启动模式
默认值: OnDemand(按需运行模式), 另外值 AlwaysRuning(始终运行模式)
优化设置: 改为 AlwaysRunning(始终运行)
步骤三, 设置站点预加载
在 IIS 上站点右键>管理网站>高级设置, 把[预加载已启用] 设置为 true.
步骤四, 配置站点 Web.config, 添加站点重启后预加载请求的页面
eg: 地址: 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="**" /> 子节点
六, 并发性
常规>队列长度
HTTP.sys 将针对应用程序池排队的最大请求数. 默认值 1000, 最大值 65535.
如果设置太大则会消耗大量的系统资源 , 而设置太小会导致客户端访问时频繁出现 "503 服务不可用" 响应.
优化设置: 可先改为 5000(设置为预期最多并发用户数的 1.5 倍, 官方参考
使用 Windows 性能监控(性能监控: cmd->perfmon.msc), 添加 "HTTP Service Request Queues/CurrentQueueSize" 指标, 观察某个应用程序池当前队列中请求的个数.
启用 Web 园, 进程模型>最大工作进程数
在 Web 园中你可以配置此应用程序池所使用的最大工作进程数, 默认为 1, 最大可以设置为 4000000; 配置使用多个工作进程可以提高该应用程序池处理请求的性能, 但是在设置为使用多个工作进程之前, 请考虑以下两点:
1, 每一个工作进程都会消耗系统资源和 CPU 占用率; 太多的工作进程会导致系统资源和 CPU 利用率的急剧消耗;
2, 每一个工作进程都具有自己的状态数据, 如果 Web 应用程序依赖于工作进程保存状态数据, 那么可能不支持使用多个工作进程.
这样设置, 增加了处理进程数, 相当于集群, 避免大量请求处于排队状态
参考:
IIS 并发优化
文章介绍: 使用 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 并发请求设置如何设置?
站点最大并发连接数
右键站点>高级设置>限制>最大并发连接数
七, 安全性
为不同工作进程指定应用程序池(工作进程隔离模式)
一台服务器上有非常多的 Web 站点. 如何才能做到各个站点之间相互独立, 不因某些 Web 站点出现故障而影响其他站点呢?-- 为不同工作进程指定应用程序池是个很好的解决办法.
进程模型>标识, 使用 ApplicationPoolIdentity 虚拟账户
ApplicationPoolIdentity - 默认情况下, 选择 "应用程序池标识" 帐户. 启动应用程序池时动态创建 "应用程序池标识" 帐户, 因此, 此帐户对于您的应用程序来说是最安全的.(这样, 每个应用程序池都有各自的账户, 就避免了木马上传到其中一个池下站点, 会对另一个池的文件夹有操作权限)
参考:
IIS7.5 中神秘的 ApplicationPoolIdentity
启用快速失败保护
如果 Web 应用程序代码编写有问题, 它可能会导致工作进程持续出现问题. 默认情况下应用程序池配置为启用快速失败保护, 当工作进程在配置的时间段 (默认为 5 分钟) 内发生的失败次数超过了配置的值(默认为 5 次), 则禁用此应用程序池.
===========================================================
over, 谢谢查阅, 觉得文章对你有收获, 请多帮推荐. 欢迎提供更好的资料信息.
来源: https://www.cnblogs.com/heyuquan/p/deploy-iis-set-performance-guide.html