ASP.NET WebAPI从Web应用目录跳转至Action路由环节出现不明延迟

可能的原因及排查方案 #

这个发生在业务代码执行前的秒级延迟和路径转发本身的逻辑无关，正常IIS路由/重写的执行耗时都在微秒到毫秒级，出现秒级阻塞一般是以下几类原因：

• 应用池冷启动：你使用的DefaultAppPool默认是按需启动模式，如果是应用池回收后首次接收到请求、或是长时间没有请求触发了空闲回收，IIS需要先完成w3wp进程启动、CLR运行时初始化、Web应用域加载、配置文件解析、全局模块注册等一系列前置操作，所有这些操作都发生在业务代码（包括Auth模块）执行之前，和你观察到的特征完全匹配。
  验证方式：连续多次调用同一个接口，若后续请求无该延迟即可确认。解决方法是将应用池启动模式修改为AlwaysRunning，同时开启应用预加载功能，避免空闲回收后的冷启动开销。
• APM模块阻塞：你启用的SignalFx链路追踪会在IIS管道的最早阶段注入原生模块，完成链路上下文解析、采样规则匹配、元数据采集等操作，如果这部分逻辑存在同步阻塞（比如本地日志写入加锁冲突、远程配置拉取超时、本地DNS查询失败等），就会卡住整个请求流程，直到模块逻辑执行完成才会进入后续步骤。
  验证方式：临时移除SignalFx的IIS模块注册后重试，若延迟消失即可定位问题根因。
• 路由规则遍历阻塞：IIS处理虚拟应用下的请求时，会先执行站点级的URL重写规则，再执行虚拟应用级的规则，如果站点级配置了大量正则匹配的重写/重定向规则，每个请求都需要遍历全量规则做匹配，规则量级足够大时也会出现秒级耗时。如果配置了错误的自跳转规则，导致请求在IIS内部循环跳转也会累计出大量耗时。
  验证方式：开启IIS的失败请求跟踪（FRT）功能，针对200状态的请求开启跟踪，可直接看到每个IIS管道步骤的具体耗时，精准定位阻塞点。
• 请求排队：只有当应用池请求队列满、或是配置了动态限流规则时才会出现请求被重新入队的情况，你可以查看Windows性能计数器ASP.NET\Requests Queued，如果延迟发生时该计数器数值大于0，才说明发生了请求排队，否则可以排除该可能性。

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