旧版ASP.NET 4.x迁移至AWS EC2 Server 2019后性能骤降求助

一、IIS 7.x到IIS 10的关键默认设置差异 #

• 应用池队列长度：IIS 7.x默认队列长度是1000，而IIS 10直接降到了100。当多个应用跑起来并发请求上来时，这么小的队列很容易导致请求排队阻塞，直接引发卡顿。试试用命令调整：appcmd set config /section:applicationPools /[name='你的应用池名称'].queueLength:1000
• .NET Core托管模式：IIS 10对.NET Core默认用OutOfProcess模式，而旧版IIS只能用InProcess。OutOfProcess模式下每个应用会多跑一个dotnet.exe进程，进程间通信的开销或者端口竞争都可能拖慢性能。可以在应用的web.config里加一行<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>，减少进程切换的损耗。
• CPU回收逻辑：IIS 10默认是禁用CPU阈值回收的，和IIS 7.x不一样。去检查下应用池的CPU设置，确认“CPU超过阈值时回收”有没有开，另外IIS 10默认是按进程监视CPU，得改成应用池级别的监视才管用。
• 快速失败保护：IIS 10默认开了快速失败保护，要是应用池5分钟内崩溃5次就会被禁用。哪怕你没看到明显崩溃，要是应用有隐性的启动失败，也可能导致部分应用池被限制，间接搞出卡顿。可以先关了试试：appcmd set config /section:applicationPools /[name='你的应用池名称'].failure.rapidFailProtection:False

二、AWS EC2的潜在坑点 #

• 网络性能瓶颈：物理服务器是本地网络，EC2的网络是共享的（除非用独占实例或增强型网络）。多个应用同时对外通信时，很可能碰到带宽不够或者延迟波动。去AWS CloudWatch里看EC2的网络入/出流量，有没有带宽饱和；另外一定要启用弹性网络适配器（ENA），能提升不少网络性能。
• 存储IO拖后腿：如果应用用本地磁盘存日志、临时文件，EC2默认的gp2卷在高并发下IOPS很容易不够用，物理服务器的本地磁盘IO可比这稳多了。去看EBS卷的IOPS指标，不行就升级到gp3或者Provisioned IOPS卷；要是实例支持本地存储，把临时文件迁过去也行。
• CPU信用耗尽：如果用的是t2/t3这类Burstable实例，有CPU信用机制，长时间超基准值用就会被限性能。哪怕你看到CPU最高才10%，也可能已经把信用耗光了，实际处理能力上不去。要么换成m5/c5这类固定性能实例，要么去CloudWatch看CPUCreditBalance指标确认下。

三、关于增加工作进程数的注意事项 #

加工作进程（也就是开Web Garden）确实能提升并发，但有几个坑得注意：

• 要是应用用了内存会话，InProcess模式下开Web Garden会导致会话丢失，因为不同进程没法共享内存。这种情况得换成Redis之类的分布式会话。
• 20个应用每个都开多个进程，哪怕现在内存占用低，后续可能触发频繁的内存回收，反而更卡。建议先挑一个卡顿的应用池测试，从2个进程开始，看性能变化再调整。

四、额外排查步骤 #

• 开IIS日志和失败请求跟踪，看看卡顿的请求是排队时间长还是处理时间长，精准定位瓶颈。
• 用Windows性能监视器（PerfMon）盯着ASP.NET Core的计数器，比如Requests Queued、Current Requests，还有IIS Application Pool的Queue Length、Active Requests，确认是不是请求排队导致的卡顿。
• 翻Windows事件日志（应用程序、系统日志），看看有没有IIS或者.NET Core的警告/错误，比如端口占用、文件权限问题。

内容的提问来源于stack exchange，提问作者hooray4bw