ASP.NET 4.7.2 Web Api运行小查询时IIS超时问题排查咨询

• 排查IIS请求管道阻塞问题
  开启IIS失败请求跟踪（FRT），配置规则匹配超时状态码（通常为502.3、504），确认请求卡在管道的具体阶段：如果卡在BeginRequest之前，说明IIS工作进程资源耗尽；如果卡在ExecuteRequestHandler阶段，说明应用层代码出现阻塞，还未执行到数据库调用环节。
• 检查Linq to Sql上下文配置与连接池状态
  使用性能监视器（PerfMon）查看*.NET Data Provider for Sql Server*分类下的NumberOfPooledConnections、NumberOfActiveConnections计数器，如果活跃连接数长期接近连接字符串配置的Max Pool Size（默认值为100），即可判定为连接池泄漏。优先检查代码中DataContext实例是否使用using块包裹，是否存在遗漏释放的场景。
• 验证路由与前置中间件逻辑
  请求未到达SQL Server大概率是执行到数据库访问代码前就被阻塞，可在接口入口、数据库调用代码前分别添加落地日志，确认请求执行到哪一步中断。重点排查自定义鉴权、限流、日志中间件是否存在死锁，是否存在.Result/.Wait()这类同步调用异步方法的写法，这类写法极易引发线程池饥饿，导致后续请求无可用线程执行。
• 核对IIS应用池配置
  确认应用池.NET CLR版本设置为v4.0，「启用32位应用程序」配置与项目生成平台匹配，检查是否配置了请求过滤、IP限制、URL重写规则拦截了正常请求，同时查看应用池队列长度是否设置过小导致请求排队超时。

• 修复连接池泄漏
  所有DataContext实例必须用using代码块包裹，确保操作完成后自动释放连接，示例写法：

using (var db = new YourCustomDataContext())
{
    // 数据库操作逻辑
}

如果通过依赖注入注入DataContext，必须将生命周期设置为Scope/Request级别，禁止使用单例模式。

• 解决线程池饥饿
  全链路移除.Result/.Wait()这类同步阻塞写法，所有异步调用统一用await关键字，接口方法标记为async Task<T>返回类型。如果旧代码改造难度大，可在web.config的<appSettings>节点下添加配置缓解阻塞：

<add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" />

• 优化IIS配置
  高并发场景下可将应用池「队列长度」从默认1000调整到5000，「最大工作进程数」按服务器CPU核心数调整（通常为核心数的1-2倍，使用进程内缓存的场景需要额外考虑多进程缓存同步问题）。同时按需调整接口执行超时时间，在web.config的<system.web>节点下添加配置：

<httpRuntime executionTimeout="120" />

上述配置的超时单位为秒。

• 优化Linq to Sql调用逻辑
  确认Linq to Sql生成的存储过程调用代码的参数类型，和SQL Server侧存储过程的参数类型完全匹配，避免隐式类型转换引发的执行计划异常。可在DataContext构造逻辑中手动设置命令超时时间，覆盖默认30秒的限制：

db.CommandTimeout = 60;

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