求助排查IIS应用程序池回收后首请求响应时间差异过大问题

优先排查容易遗漏的非IIS配置差异 #

之前仅核对了IIS管理器内的站点、应用池参数，以下主机层面的差异是仅检查IIS配置无法覆盖的，需优先交叉核对：

• 运行时版本一致性：在两台服务器执行dotnet --list-runtimes，对比已安装的.NET Core运行时的版本、发布渠道（正式版/预览版），排除B服务器存在多版本运行时错配、预览版运行时加载性能劣化的问题。
• 安全软件扫描规则：检查Windows Defender（或第三方杀毒软件）的实时扫描规则，确认是否排除站点部署目录、.NET Core运行时安装路径、IIS工作进程（w3wp.exe）。站点首次启动需要加载数百个程序集，未做排除时逐文件安全扫描带来的延迟，很容易达到10倍级别的差距。
• 主机资源占用状态：在两台服务器同步观察CPU、磁盘IO、网络的实时占用，确认B服务器是否存在后台服务占满磁盘带宽、CPU的情况。Standard D11 v2本身基础磁盘IO能力有限，少量资源抢占就会直接拉高首次程序集加载的延迟。
• Azure虚拟机底层配置：交叉核对两台VM的临时磁盘挂载状态、磁盘加密策略，排除B服务器因启用额外磁盘审计、全盘加密校验导致的文件读写延迟。

拆分启动流程定位慢响应的具体环节 #

不要只盯着首个请求的总响应时间，需拆分流程逐段对比耗时：

• 应用自身初始化耗时：在程序入口添加Stopwatch计时，分别记录从Main函数入口、完成依赖注入注册、完成中间件管道配置、启动Kestrel监听的各段耗时，对比两台服务器上应用代码自身运行的总时长。如果这部分耗时和A服务器一致，说明问题出在应用进程加载、IIS管道层面；如果这部分耗时本身偏高，再向下排查应用启动逻辑。
• 启动阶段隐式外部依赖：即使是内置天气预报接口的官方模板项目，也要确认启动流程中是否存在隐式的外网请求（比如拉取云服务元数据、请求远程配置接口），如果B服务器存在网络连通性异常，这类超时等待会直接把启动耗时拉高一个数量级。

可用于定位根因的诊断工具 #

• dotnet-trace：可直接附加在首次启动的应用进程上，抓取启动全流程的采样跟踪，能清晰识别启动阶段哪个模块占用最多CPU时间、存在哪些锁等待、文件IO阻塞点。
• typeperf：通过系统性能计数器，实时采集应用池回收时间段的CPU、磁盘、网络指标，快速定位是否存在系统层面的资源瓶颈。
• Windows Performance Recorder/WPA：抓取全系统级别的跟踪日志，可完整复现从w3wp.exe进程启动、ASP.NET Core原生模块加载、到应用进程内部初始化的全链路耗时，通过和正常服务器的跟踪结果对比，直接定位到耗时异常的环节。
• IIS内置诊断日志：将ASP.NET Core Module（ANCM）的日志级别调整为调试模式，可记录模块启动子进程、管道转发请求的每一步耗时，排查模块加载阶段的异常。

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