做站久了，最怕的不是服务器被人打，而是这种说不清道不明的慢：同一台机器、同一套程序，前一阵点开网页还是唰唰的，最近却总要转上两三秒，重启一下 IIS 立马跟没事一样，过两天又开始磨叽。很多人第一反应是程序写得烂，或者怪线路抖，其实在 Windows 服务器上，相当一部分卡顿是 IIS 自己的默认设置在拖后腿：应用程序池按时回收、压缩没开、动态页面没有缓存、php-cgi 的进程数给得太保守。这篇不聊虚的，就按 IIS 管理器的菜单顺序，从应用程序池一路调到失败请求跟踪，照着做就能见效。
打开慢先分清卡在哪一层，别上来就改配置
动手之前先花三分钟确认，能省下半小时瞎折腾。打开浏览器开发者工具的网络面板看首字节时间：首字节就要好几秒，问题在服务器端，跟图片大小、CDN 关系不大；只有第一次慢、之后很快，八成是应用程序池闲置回收，进程被挂起等着人去唤醒；每隔半小时到一小时固定顿一下，就要怀疑定时回收；而首字节很快、后面加载慢，那多半是静态资源和带宽的事，改 IIS 是白费劲。更细一点的判断是去 IIS 管理器看站点对应的应用程序池，在运行状况里瞄一眼 CPU 和内存：CPU 长期打满，就往压缩和 PHP 实例数上找；内存一路往上涨不回落，就往回收策略上找。分不清层次就上手改配置，只会越调越乱。
应用程序池闲置超时：别让站点没人访问时就睡死
IIS 管理器左边展开服务器，点「应用程序池」，右侧选中你站点用的那个池，再点操作栏里的「高级设置」。找到「进程模型」下面的「闲置超时（分钟）」，默认是 20 分钟。它的意思是：这段时间没有请求进来，工作进程就会被挂起甚至回收，等下一个访客或者蜘蛛来了，系统得重新把进程拉起来、PHP 重新加载一遍扩展和代码，第一次打开自然就慢，爬虫碰上这种情况还容易直接超时走人。判断标准很简单：流量不大却要求打开快的小站，把闲置超时设成 0，也就是永不闲置；内存本来就紧张的老机器，改成 240 或者 480，让它白天别反复睡下去也行，别死守默认值。改完记得回收一次应用程序池让设置立刻生效。
固定回收间隔 1740 分钟，周期性卡顿的常见元凶
同一个「高级设置」面板里还有「回收」一节，里面「固定时间间隔（分钟）」默认写着 1740，换算下来大约每 29 个小时回收一次进程；旁边「特定时间」默认还会在凌晨给你排一次。回收本身不是坏事，能防内存泄漏，但回收的那一瞬间，正在处理的请求会被打断，进程内的缓存全清空，包括 opcache 和一部分输出缓存，表现出来就是每隔一阵网页顿一下、后台莫名掉登录。做法很土但管用：把「固定时间间隔」改成 0 关掉按钟点回收，再在「特定时间」里挑凌晨三四点这种没人访问的时段补一条；同时给「虚拟内存限制」和「专用内存限制」设个阈值，进程内存涨到一定程度自动回收，按实际需要回收比死按时钟回收聪明得多。
压缩要开对：静态压缩和动态压缩分工不同
在 IIS 管理器里选中站点，打开「压缩」功能，两个勾都点上：启用静态内容压缩、启用动态内容压缩。静态压缩针对 html、css、js 这些文件，第一次请求时压好存到磁盘，之后直接发压缩包，CPU 开销可以忽略，是最划算的一刀；动态压缩是每个请求当场压，吃 CPU，但页面 HTML 动辄几十上百 KB，压完体积能小一截，首屏时间肉眼可见地降。两个坑要记住：静态压缩需要磁盘缓存目录，默认在系统盘，小硬盘的机器最好换个盘，并且确认 IIS_IUSRS 有写权限，不然压完存不下等于白干；动态压缩的 MIME 类型列表默认不一定包含 text/html，不加上去它对页面根本不生效，要在配置里补上。还有，程序自己已经 gzip 过就别再让 IIS 压一遍，重复压缩反而更慢。
给动态页面配输出缓存，别每次都从头算一遍
站点下面有个「输出缓存」功能，点进去用右边的「添加」新建一条规则。很多人以为它只认静态文件，其实扩展名填成 .php 一样能用，把栏目页、列表页这类短时间内内容不变的动态页面缓存起来，规则里设一个缓存时长，先给 30 到 60 秒，稳了再往上加。它有两种模式：内核模式缓存在系统内核层最快；用户模式缓存在工作进程里，能用更多变量做区分。最容易踩的坑是登录态：带 cookie 的登录用户和后台页面被缓存出去，访客可能看到别人的用户名，后台改完文章半天不更新。所以规则要收窄，只缓存匿名访客访问的、不带查询串的地址，后台目录直接排除在外。输出缓存和动态压缩可以一起用，缓存下来的响应照样能压缩后再发出去。
FastCGI 设置：php-cgi 的实例数和两个超时要配合
Windows 上跑 PHP 一般走 FastCGI。在 IIS 管理器点服务器节点，双击「FastCGI 设置」，选中列表里 php-cgi.exe 那行点「编辑」，有三个值值得动。「最大实例数」决定同时起多少个 php-cgi 进程，默认是 0，很多环境实际只起很少几个，并发一上来请求就排队。定多少合适？先看空闲内存，一个带着常用扩展的 php-cgi 进程通常占几十 MB，把实例数定在可用内存的大半除以单进程占用，宁可少一点也别压到换页。「活动超时」默认 30 秒，管实例空闲多久被回收，调小省内存、调大省反复启停的开销；「请求超时」默认 90 秒，管单个请求最长跑多久，导出备份老失败就放宽它，并和 php.ini 里的 max_execution_time 对齐。
失败请求跟踪：把 5 秒以上的慢请求揪出来
前面几项靠经验，想精准定位就得请出「失败请求跟踪」。先在服务器节点的「失败请求跟踪」里点「启用」，再到站点下面的「失败请求跟踪规则」里添加一条规则，可以按 URL 指定可疑页面，也可以在「定义跟踪条件」里选「耗时（秒）」填 5，意思是一个请求超过 5 秒就记一份日志。日志默认落在系统盘 inetpub 的 logs 下面的 FailedReqLogFiles 文件夹里，格式是 XML，用浏览器打开逐行看，每行都带时间戳和模块名，哪一步吃掉了大部分时间一眼就能看出来：停在 FastCGI 上说明 PHP 执行慢，停在压缩环节是 CPU 不够，停在静态文件多是磁盘 IO 有问题。提醒一句，它很吃磁盘写入，只挂在你怀疑的几个地址上，找到原因就关掉，别全站开着当监控。
调完怎么验收，还有几个容易翻车的地方
每改一项都拿数据说话，别凭感觉。用开发者工具看首字节时间和总耗时，同一个页面改动前后各测三遍，最好换个外地网络或用在线测速对比一次，只在自己电脑上感觉快说明不了什么。有空就挂一天性能监视器，盯住 w3wp.exe 和 php-cgi.exe 的内存与 CPU 曲线。几个容易翻车的地方再念一遍：动配置前备份 applicationHost.config 和站点的 web.config，IIS 管理器里改的东西大多写在这两处，改坏了整个站点都起不来；输出缓存规则先短时长上线，确认没有串号再加长；内存不宽裕的机器别为了好看把实例数拉满，压到换页反而全场变慢；所有默认值和推荐值都只是参考，以你机器上的实际显示和官方页面说明为准。
再把顺序捋一遍：先把应用程序池的闲置超时和固定回收间隔改成贴合自己流量的样子，再把静态压缩、动态压缩打开，给内容不常变的动态页面配上输出缓存，然后按内存把 FastCGI 的实例数和两个超时调协调，最后用失败请求跟踪把超过 5 秒的请求一个个抓出来定位。这一套走下来，Windows 服务器上多数的打开慢都能收住。别指望一项设置解决所有问题，IIS 调优说到底是个细活儿，改一点、测一点、记一点，机器迟早会给你回报。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
