在如今这个以毫秒计胜负的Web时代，IIS服务器作为Windows环境下最核心的Web服务平台，其性能调优往往被许多运维人员视为“黑盒”操作。大多数管理员习惯于默认安装、默认配置，直到遭遇高并发下的瓶颈才追悔莫及。事实上，IIS的优化并非玄学，而是可以通过几个关键节点的精准调整，撬动成倍的性能提升。本文将直接切入实操层面，揭示那些常被忽略却能带来立竿见影效果的五个核心配置项。
IIS最独特的优势在于其HTTP.sys驱动直接运行在内核态。许多管理员只知道开启静态文件缓存，却对内核模式缓存（Kernel Cache）的精细控制缺乏认知。默认情况下，HTTP.sys会缓存响应内容，但若你的站点频繁返回动态内容，缓存命中率会急剧下降。关键在于，通过netsh http add cacheparam指令可以调整缓存段的TTL与大小限制。对于图片、CSS、JS这类静态资源，建议将UriEnableCache设置为1，并将UriMaxUriBytes提升至足以容纳最大静态对象的大小。更进阶的做法是，针对特定应用池，在applicationHost.config中为serverRuntime节点配置appConcurrentRequestLimit属性，将其从默认的5000提升至10000以上，以消除高并发下内核队列的瓶颈。
IIS应用池的默认回收机制（每1740分钟，即29小时）是性能波动的主要元凶。当回收发生时，工作进程（w3wp.exe）被强制终止，所有会话状态与内存中的缓存数据瞬间丢失，造成请求排队和延迟尖峰。优化方向并非关闭回收，而是将其变为“可预测”且“无感”的操作。首先，在应用池高级设置中，将闲置超时从默认20分钟修改为0（永不超时），避免闲时回收引发的首请求冷启动。其次，启用特定时间回收，将回收点设定在凌晨流量低谷，并勾选禁用重叠回收的替代方案——实际上应启用“重叠回收”功能，让旧进程处理完现有请求后再释放内存，新进程预先启动接管流量。对于内存敏感的64位系统，务必设置私有内存限制（如4GB），但需配合回收时间间隔的随机偏移，防止多个应用池同时回收造成CPU尖峰。
多数IIS部署仅启用了动态压缩（Dynamic Compression），却忽略了静态压缩的优先级。实际上，开启静态内容压缩（Static Compression）能对JS、CSS、SVG等文件产生高达70%的压缩率。但这里有个隐藏陷阱：默认的CPU阈值为100%时才会启用压缩，这导致在低配置服务器上压缩模块形同虚设。建议将cpuPercentage限制调整为40%，并将maxDiskSpaceUsage提升至100MB以上以缓存压缩副本。另外，务必为application/json和application/javascript MIME类型手动添加到压缩白名单中，因为默认列表并不包含它们。配合HTTP/2协议启用，压缩带来的延迟削减会更加明显。
IIS的connectionTimeout默认值为120秒，这在不稳定的网络环境下会导致大量僵尸连接占据线程池。建议缩短至30-45秒之间，并同时调整maxConcurrentRequestsPerCPU（默认为10）。如果你的站点大量依赖Ajax轮询或WebSocket长连接，则需要将minBytesPerSecond调低至240（默认值），避免低速连接被提前切断。更关键的是keepAliveTimeout与headerWaitTimeout的搭配：前者建议设置为5秒，后者保持默认15秒即可。过于激进的Keep-Alive设置反而会增加TIME_WAIT状态连接数，因此务必监控netstat -an中TIME_WAIT的数量，如果超过总连接数的20%，则应适当上调keepAliveTimeout。
默认的IIS日志（W3C格式）会记录每一个请求的完整字段，包括User-Agent、Referer等，在高流量下，磁盘I/O会被日志写入拖垮。优化策略是分两步走：第一步，在日志字段选择中，仅保留date、time、cs-uri-stem、sc-status、time-taken这五个核心字段，弃用cs(User-Agent)和cs(Referer)。第二步，将日志文件路径迁移至独立的物理磁盘（或SSD卷），并设置日志文件滚动周期为每日，而非默认的每小时。更彻底的做法是，利用Failed Request Tracing替代永久日志——仅在特定错误码（如500或503）时触发详细跟踪，平时零开销。此外，建议开启httpSys级别的队列长度监控，通过性能计数器Web Service\\Current Connections与HTTP Service Request Queues\\RejectedRequests的比值，来判断是否已达优化天花板。
以上五项配置并非独立存在，它们彼此影响。例如，内核缓存的命中率提升会减少应用池的CPU负载，而压缩策略的优化又会降低网络延迟，进而影响连接超时的设置效果。真正的IIS优化是一个动态调优的循环过程，建议每次调整后，利用LoadGen或ApacheBench进行基准测试，观察吞吐量（RPS）与错误率的变化趋势。记住，没有一套配置适用所有场景，但基于HTTP.sys、应用池回收、压缩、连接管理、日志诊断这五个支点，你已握住了IIS性能跃迁的钥匙。