IIS是Windows环境下部署Web应用的标配组件，但迁到Azure虚拟机之后，硬件不再是物理服务器，性能表现会受到实例规格、磁盘类型、网络带宽等多重因素影响。很多团队照搬本地物理机的IIS配置直接上云，结果发现并发能力不如预期，甚至出现请求排队超时的情况。这篇文章围绕Azure虚拟机上的IIS展开实测分析，聊聊不同实例规格下的真实表现，以及如何通过配置调优把性能拉起来。
实例规格对IIS性能的影响有多大
Azure的虚拟机按系列划分，不同系列的CPU主频、内存配比差异明显。对IIS这种典型Web负载来说，B系列（突发型）和D系列（通用型）是最常见的选择。B系列便宜，但CPU积分耗尽后会被严重限流，一旦你的站点流量出现持续高峰，CPU就会被压到基准线的百分之二十左右，表现为页面响应从几十毫秒恶化到数秒。而D系列v4、v5提供稳定的vCPU配额，更适合长期运行的Web服务。
我们在Standard_D4s_v5（4核16GB）和Standard_B4ms（4核16GB）上做了对比测试，使用wrk模拟500并发持续压测一个ASP.NET Core站点。结果差异非常直观：D4s_v5稳定跑出约7800次请求每秒，P99延迟在45毫秒左右；B4ms在积分充足时也能接近这个数字，但持续压测5分钟后积分耗尽，吞吐直接掉到1500次请求每秒以下，延迟飙到800毫秒以上。结论很清楚：测试或低流量站点可以用B系列省钱，生产环境的IIS请直接选D系列起步。
另外要注意vCPU与IIS工作进程的关系。默认情况下IIS的应用程序池每个工作进程只占一个逻辑核，如果你的机器是4核但站点只有单应用程序池单进程，实际上只吃满了一个核，剩下的算力都在闲置。这种情况下要么在应用程序池高级设置里调整CPU限制，要么在代码层面做并行化处理，否则升配多核机器带来的收益非常有限。
磁盘与网络：容易被忽视的瓶颈
IIS站点的日志写入、静态文件读取、应用池回收时的临时文件操作都依赖磁盘IO。Azure虚拟机的默认磁盘性能和挂载的托管磁盘类型直接挂钩，标准HDD和高级SSD之间差距能到十倍以上。我们建议系统盘和IIS站点目录所在的数据盘都至少使用高级SSD（Premium SSD），对应的配置文件位于站点的物理路径设置中，比如默认的C:\inetpub\wwwroot，如果流量较大，建议把站点迁移到独立数据盘如D:\Sites下，避免和系统盘抢IO。
IIS日志默认写在C:\inetpub\logs\LogFiles目录，高流量站点的日志写入量非常可观。一个折中方案是适当延长日志刷新，或者把日志目录迁移到独立磁盘。修改方法是在IIS管理器中选中站点，进入日志功能，将目录改到D:\Logs\IIS这样的独立路径，同时确保该路径所在磁盘的缓存配置合理。
网络方面，每个Azure虚拟机规格都有明确的网络带宽上限，比如D4s_v5大约能跑到12500 Mbps出口。对纯文本类响应通常不是瓶颈，但如果你的站点大量输出图片、视频等大文件，就要确认实例的网络加速（Accelerated Networking）已经开启。可以在PowerShell中执行以下命令检查并启用：
# 检查虚拟机是否启用了加速网络
Get-AzVM -ResourceGroupName "MyRG" -Name "MyWebVM" | `
Select-Object -ExpandProperty NetworkProfile
# 对现有虚拟机启用加速网络（需先停止虚拟机）
Stop-AzVM -ResourceGroupName "MyRG" -Name "MyWebVM"
$nic = Get-AzNetworkInterface -ResourceGroupName "MyRG" -Name "MyWebVM-NIC"
$nic.EnableAcceleratedNetworking = $true
$nic | Set-AzNetworkInterface
Start-AzVM -ResourceGroupName "MyRG" -Name "MyWebVM"启用后网络中断的处理开销会显著降低，高并发小请求场景下CPU占用率能下降一到两成，这对IIS这种每请求都要走完整HTTP管线的服务来说是实打实的收益。
IIS自身的调优手段
第一个要动的是应用程序池回收策略。默认配置是每1740分钟（29小时）定期回收，这个机制对云环境并不友好，回收瞬间请求会被挂起甚至丢弃。建议在应用程序池高级设置中把定期回收改到业务低峰时段，并开启重叠回收，让新进程先就绪再停掉旧进程。同时把空闲超时从默认20分钟调整到0，避免低流量时段工作进程被反复杀掉导致冷启动。
<!-- applicationhost.config 中的应用程序池配置示例 -->
<application path="/" applicationPool="MyWebPool">
<applicationPoolDefaults>
<recycling>
<periodicRestart time="04:00:00" />
<periodicRestart requests="0" />
</recycling>
<processModel idleTimeout="00:00:00" />
</applicationPoolDefaults>
</application>第二个手段是输出缓存与HTTP压缩。对不常变化的动态页面，可以在web.config中配置输出缓存，把渲染结果缓存几分钟，命中率上去之后CPU负载会断崖式下降。HTTP压缩则对文本类资源效果明显，开启gzip后HTML、CSS、JS的传输体积通常能压缩到原来的三成左右，直接改善用户感知的首屏速度。
<system.webServer>
<urlCompression doStaticCompression="true" doDynamicCompression="true" />
<caching>
<profiles>
<add extension=".html" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" />
<add extension=".ashx" policy="CacheForTimePeriod"
duration="00:05:00" kernelCachePolicy="DontCache" />
</profiles>
</caching>
</system.webServer>第三个是队列与线程配置。HTTP.sys的队列长度默认是1000，高并发场景下可以在站点的高级设置里把队列长度提到5000甚至更高，配合应用程序池的最大工作进程数做负载均衡。不过要谨慎使用Web Garden模式（多工作进程），因为进程间不共享内存缓存，用了之后session和内存缓存方案都要改造，除非单进程确实是瓶颈，否则不建议轻易开启。
几个常见的踩坑点
第一个坑是临时文件夹路径问题。Windows的默认临时目录在C:\Windows\Temp，如果IIS应用程序池的标识账号对该目录权限不足，上传文件、编译动态页面时会莫名报错。建议在环境变量或应用程序配置中显式指定临时目录到一个权限宽松的路径，并确认应用程序池账号有读写权限。
第二个坑是杀毒软件扫描。Azure上如果自行安装了杀毒软件，务必把IIS相关目录加入排除列表，包括C:\inetpub\wwwroot、C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files以及站点自身的bin目录。我们实测过，未加排除时动态请求的吞吐量下降接近四成，这是因为每次加载程序集都会触发实时扫描，代价非常高。
第三个坑是忽略监控。Azure Monitor配合性能计数器可以直观看到IIS的运行状态，建议重点盯这几个计数器：ASP.NET\Requests Queued、ASP.NET\Requests Rejected、Web Service\Current Connections以及处理器队列长度。请求队列持续增长说明后端处理能力不足，Rejected计数非零则意味着队列已满开始丢弃请求，这两种情况都需要扩容或优化代码。把这些指标接进告警规则，才能在用户抱怨之前发现问题。
总体来看，Azure虚拟机上的IIS性能天花板并不低，关键在于规格选型合理、磁盘网络不留短板、IIS配置贴合云端特点。D系列实例加高级SSD再加一套调优后的配置，承载日均百万级请求的常规Web应用完全没问题，剩下的瓶颈往往就回到应用代码本身了。
Azure虚拟机IIS性能Windows Server修改时间：2026-09-03 14:03:21