IIS最大并发连接数极高仍可能耗尽连接吗？如何排查请求延迟问题

日志耗时不一致的原因 #

两个日志的统计时间范围完全不同是核心诱因：

• Application Insights统计的是应用程序实际处理请求的时长：计时起点是请求进入应用运行时管道（比如ASP.NET管道），终点是应用程序完成响应内容生成，这段时间只覆盖应用本身的业务逻辑处理耗时。
• IIS日志的time-taken字段统计的是请求全链路耗时：计时起点是IIS收到客户端发来的第一个请求字节，终点是IIS把最后一个响应字节发送给客户端完成，以下几个阶段的耗时都不会被Application Insights统计，直接导致IIS日志耗时更长：
  • 请求进入应用前的排队耗时：IIS应用池请求队列、运行时请求队列积压时，请求还没到达应用就会进入等待，这段耗时仅会被计入IIS日志
  • 响应内容的网络传输耗时：如果客户端网络差、带宽低，IIS发送响应的过程会被拉长，此时应用早已完成请求处理停止计时，但IIS要等响应完全发送才会结束计时
  • IIS内置/自定义模块的处理耗时：认证、重写、压缩、反向代理等IIS模块的处理逻辑全部发生在应用层之外，耗时只会被计入IIS日志
  • 大文件上传/下载的传输耗时：如果请求包含大体积的表单数据，或者响应是大文件，完整收发包的时间差会被全部算进IIS耗时，而Application Insights仅会统计应用处理文件的时间。

最大并发连接数拉满也可能出现连接耗尽 #

IIS全局的Maximum Concurrent Connections仅限制内核层面允许的最大TCP连接数，实际业务中以下限制的优先级远高于这个参数，就算参数拉满也会出现请求排队、连接被占满的情况：

• IIS应用池默认的队列长度限制（默认值通常为1000），队列满之后新请求会直接返回503错误
• 应用运行时的并发请求限制：比如经典ASP.NET默认的maxConcurrentRequestsPerCPU仅为12，并发处理能力远远低于连接数上限
• 服务器硬件资源瓶颈：CPU、内存、磁盘IO、网络带宽任意一项被打满，都会导致请求处理速度变慢，连接被长时间占用无法释放。

IIS层请求延迟的排查方向 #

• 首先查看IIS实时运行指标：打开IIS管理器的「工作进程」视图，选中对应站点的应用池，查看当前排队请求数、当前正在处理的请求数，如果排队请求数长期大于0，说明应用处理能力不足，请求在进入应用前就已经开始排队。
• 启用IIS失败请求追踪（FRT）：配置规则捕获耗时超过指定阈值（比如1秒）的请求，FRT日志会拆分请求在IIS每个管道步骤、每个模块的处理耗时，可直接定位延迟发生的具体阶段。
• 检查应用池与运行时配置：
  • 执行PowerShell命令Get-ItemProperty "IIS:\AppPools\你的应用池名称" -Name queueLength查看应用池队列长度配置，可根据业务情况适当调大
  • 对于ASP.NET应用，检查web.config中的requestQueueLimit、maxConcurrentRequestsPerCPU配置，确认是否存在不合理的并发限制
• 排查系统资源瓶颈：通过性能监视器查看CPU使用率、内存占用率、磁盘IO队列长度、网络出口带宽占用，确认是否存在硬件资源不足的情况。
• 排查TCP层问题：用netstat或TCPView工具查看连接状态，如果存在大量TIME_WAIT、CLOSE_WAIT状态的连接，说明存在端口耗尽、客户端异常断开连接的情况，也会拉长IIS请求的总耗时。

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