Windows服务器上的IIS（Internet Information Services）是承载网站和Web应用的核心组件，而IIS日志就是你排查性能瓶颈、定位安全威胁、优化资源分配的第一手数据。很多运维人员只把IIS日志当成"记录"，从来不分析，这等于把金矿当废铁。真正要做好IIS性能调优，你必须学会从日志字段中读出请求响应时间、并发压力、错误分布和流量来源，然后针对性地调整IIS配置、应用程序池参数和系统资源。下面我直接讲怎么分析、怎么调优，全是实操层面的东西。

一、IIS日志文件在哪里、长什么样

IIS默认把日志写在C:\inetpub\logs\LogFiles\W3SVC1目录下，文件名以日期命名，比如ex240101.log。每个站点对应一个W3SVC编号，W3SVC1就是默认站点。你可以在IIS管理器里右键站点→"日志"→查看当前日志路径和格式。日志格式建议选W3C扩展格式，因为它字段最全，方便后续分析。默认字段包括：日期、时间、客户端IP、请求方法、请求URI、查询字符串、端口、用户名、客户端IP、HTTP版本、User-Agent、Referer、HTTP状态码、子状态码、Win32状态码、处理时间（毫秒）、接收字节数、发送字节数、服务实例ID、服务器端口、URI查询。

二、日志分析的核心指标和方法

分析IIS日志，你重点看四个东西：状态码分布、处理时间、请求量趋势、异常请求。状态码200代表正常，301/302是重定向，400/404是客户端错误，500/503是服务器错误。如果500错误占比超过1%，说明应用层有严重问题，需要立刻排查。处理时间（time-taken字段）是核心性能指标，正常静态资源应该在50ms以内，动态页面在200ms以内，超过1秒就要警惕。请求量趋势可以帮你判断是否遭遇DDoS攻击或者流量突增。

手动看日志效率太低，推荐用工具。Log Parser是微软官方的命令行日志分析工具，功能强大。比如你想统计每个URL的平均响应时间，可以这样写：

LogParser "SELECT cs-uri-stem, AVG(time-taken) AS avg_time, COUNT(*) AS hits FROM C:\inetpub\logs\LogFiles\W3SVC1\*.log GROUP BY cs-uri-stem ORDER BY avg_time DESC" -i:W3C -o:CSV

这条命令会输出每个URL路径的平均耗时和访问次数，直接帮你找到慢接口。如果你想找出返回500错误最多的时间段，可以用：

LogParser "SELECT TO_LOCALTIME(TO_TIMESTAMP(date, time)) AS local_time, COUNT(*) AS error_count FROM C:\inetpub\logs\LogFiles\W3SVC1\*.log WHERE sc-status >= 500 GROUP BY TO_LOCALTIME(TO_TIMESTAMP(date, time)) ORDER BY error_count DESC" -i:W3C

另外，PowerShell也能做日志分析，适合写自动化脚本定期跑。比如统计每小时请求量：

Get-ChildItem C:\inetpub\logs\LogFiles\W3SVC1\*.log | ForEach-Object { Get-Content $_ } | Where-Object { $_ -match '^\d{4}-\d{2}-\d{2}' } | ForEach-Object { ($_ -split ' ')[0..1] -join ' ' } | Group-Object | Sort-Object Count -Descending

三、从日志发现问题后的具体调优手段

找到问题只是第一步，调优才是关键。IIS性能调优涉及三个层面：IIS自身配置、应用程序池设置、操作系统层面优化。

1. 调整应用程序池回收策略

默认情况下，IIS应用程序池每隔1740分钟（29小时）回收一次，回收时会中断正在处理的请求。如果你的站点流量大，频繁回收会导致用户体验卡顿。建议在IIS管理器中打开应用程序池→高级设置，把"固定时间间隔"改为0，改用"特定时间"在凌晨低峰期回收，或者设置"虚拟内存限制"和"专用内存限制"触发回收，避免固定时间回收的问题。同时把"快速故障保护"的"最大故障数"适当调高，比如从5改到10，防止偶发错误导致整个应用池被关掉。

2. 优化线程和并发处理

IIS使用线程池处理请求，默认最大线程数是有限的。在applicationHost.config文件中可以找到相关配置：

<system.web>
  <applicationPool maxConcurrentRequestsPerCPU="5000" />
  <processModel autoConfig="true" />
</system.web>

maxConcurrentRequestsPerCPU这个值决定了每个CPU核心能同时处理多少请求，默认5000对大多数场景够用。如果你的站点是高并发API服务，可以适当提高到8000甚至10000。但注意，调高这个值会增加内存消耗，必须配合服务器物理内存来评估。

3. 开启动态压缩和静态压缩

IIS支持gzip和deflate压缩，能大幅减少传输数据量。在IIS管理器中打开"压缩"功能，勾选"启用静态内容压缩"和"启用动态内容压缩"。动态压缩对ASP.NET页面效果尤其明显，通常能减少60%-80%的传输体积。但要注意，压缩会消耗CPU资源，如果你的服务器CPU已经很紧张，需要权衡。在applicationHost.config中可以精细配置：

<httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files">
  <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
  <dynamicTypes>
    <add mimeType="text/*" enabled="true" />
    <add mimeType="application/javascript" enabled="true" />
  </dynamicTypes>
  <staticTypes>
    <add mimeType="text/*" enabled="true" />
  </staticTypes>
</httpCompression>

4. 调整连接超时和请求队列

默认连接超时是120秒，对于长时间运行的任务（比如大文件上传、报表生成）不够用。在IIS管理器→站点→高级设置中，把"连接超时"改为300或600秒。同时，"限制连接数"默认是4294967295（无限制），如果你想做流量控制，可以设一个合理的上限。请求队列长度也要关注，默认是1000，高并发场景下可以适当提高到2000-5000，但太高会导致内存占用增加。

5. 操作系统层面配合优化

IIS跑在Windows上，操作系统的TCP/IP参数也会影响性能。用netsh命令调整TCP参数：

netsh int tcp set global autotuninglevel=normal
netsh int tcp set global chimney=enabled
netsh int tcp set global dca=enabled
netsh int tcp set global netdma=enabled
netsh int tcp set global rss=enabled

这些参数开启后能让网卡分担TCP处理任务，降低CPU占用。另外，把IIS日志文件放到单独的磁盘分区，不要和系统盘、网站文件放一起，避免I/O争抢。如果条件允许，日志可以写入SSD或者通过网络写入专用日志服务器。

四、建立常态化的日志监控机制

一次性分析日志解决不了长期问题。你应该建立一个自动化监控流程：每天定时用Log Parser或PowerShell脚本跑一遍日志，生成关键指标报表（错误率、平均响应时间、Top10慢接口、异常IP列表），通过邮件或企业微信推送给运维团队。发现500错误突增、响应时间超过阈值、某个IP请求量异常，立刻告警。这样你就从"被动救火"变成"主动预防"。

五、常见误区和注意事项

很多人调优时只盯着IIS配置，忽略了应用代码本身。日志显示某个接口慢，你调了IIS参数没用，问题可能在数据库查询、外部API调用或者代码逻辑。所以日志分析要和应用性能监控（APM）结合起来看。另外，不要盲目调高所有参数，每个调整都要有数据支撑，调完之后观察日志变化，确认效果。IIS日志本身也占磁盘空间，建议设置日志文件大小上限和自动删除策略，比如单个文件不超过50MB，保留30天。

总结一下，IIS日志分析不是什么高深技术，但它是Windows服务器运维的基本功。从读懂W3C日志字段开始，用Log Parser或PowerShell做批量分析，找到性能瓶颈和异常模式，然后从应用程序池、压缩、线程、超时、操作系统TCP参数五个维度逐一调优，最后建立自动化监控闭环。这套流程跑通了，你的IIS服务器稳定性和响应速度会有质的提升。