如何检查IIS或Windows Server的出站请求限制是否已超出？
2026-8-17
排查IIS/Windows出站请求3秒延迟的方案
一、先定位延迟发生阶段
既然外部ESB、网络链路的指标都没捕捉到这3秒，延迟肯定出在你的API本地（从发起SOAP请求到实际发送至ESB，或等待响应的阶段）。先通过代码埋点精准确认：
- 在SOAP请求的前后用
Stopwatch计时，拆分记录：- 请求构建（序列化SOAP报文等）的耗时
- 调用SOAP服务的总耗时（和API监控指标对应）
- 响应解析的耗时
- 对比后就能确定3秒延迟是卡在请求发送前的本地处理，还是发起请求后等待响应的阶段。
二、性能监视器（PerfMon）必看指标
直接挑核心指标，不用遍历全部：
1. IIS应用池与.NET运行时
- .NET CLR Networking
Outbound Requests/sec：每秒发起的出站请求数，高负载下如果数值波动大或持续高位，可能接近并发瓶颈Request Queue Length：出站请求排队长度，持续增长说明请求被阻塞等待
- IIS Application Pools
Current Requests：当前处理的请求数，超过应用池Max Worker Processes或Max Concurrent Requests设置值时，请求会排队Queue Length：应用池请求队列长度，若接近设置上限（默认1000），说明并发过载Worker Process Restarts：频繁重启会导致请求中断重发，额外增加延迟
2. Windows系统网络
- TCPv4
Connections Established：当前TCP连接数，检查是否接近系统动态端口上限（默认动态端口范围是49152-65535，共16384个）Connection Failures：连接失败次数，高负载下如果次数飙升，大概率是端口耗尽导致的重试（重试等待时间通常在几秒级，符合你的3秒延迟特征）Retransmissions/sec：TCP重传次数，即使外部网络指标正常，本地TCP栈的重传也可能引发延迟
- System
Processor Queue Length：处理器队列长度，若超过CPU核心数的2倍，说明CPU过载，请求处理被阻塞Context Switches/sec：过高的上下文切换会消耗CPU资源，拖慢请求处理
3. .NET线程与内存
- .NET CLR Threads
ThreadPool Threads Count：线程池线程数，高负载下如果线程池队列堆积，会导致发起出站请求的线程等待
- .NET CLR Loading
Bytes in All Heaps：堆内存占用，内存不足引发频繁GC，会阻塞请求处理流程
三、直接检查配置限制
1. Windows动态端口限制
- 打开CMD运行：
netsh int ipv4 show dynamicport tcp，查看当前动态端口范围 - 若高负载时TCP连接数接近范围上限，会导致端口耗尽，系统需等待端口释放，这会带来几秒级延迟
- 临时调整扩大端口范围（重启生效）：
netsh int ipv4 set dynamicport tcp start=1024 num=64511
2. IIS应用池并发配置
- 打开IIS管理器→对应应用池→高级设置：
Maximum Worker Processes：默认1，高负载下可按CPU核心数调整（比如4-8）Max Concurrent Requests：默认5000，若实际并发超过此值，请求会进入队列等待Queue Length：默认1000，队列满后会拒绝请求，接近上限说明并发过载
3. .NET出站连接限制
- .NET Framework中
ServicePointManager.DefaultConnectionLimit默认是2，高负载下会导致连接排队 - 在应用启动代码中设置：
ServicePointManager.DefaultConnectionLimit = int.MaxValue;（或根据实际并发设置合理值） - 注意：
HttpClient必须复用实例，禁止每次请求新建，否则会引发连接泄漏和端口耗尽
四、其他排查方向
- SOAP客户端配置：检查是否设置了过短的超时时间，导致请求重试（不过你的延迟是3秒加实际耗时，概率较低，但需确认）
- 连接复用：确认SOAP客户端是否复用了与ESB的TCP连接，每次新建连接会增加握手耗时，高负载下累积可能引发延迟
- 防火墙/代理：检查Windows防火墙出站规则、是否有前置代理，高负载下代理排队或防火墙规则限制也可能导致延迟
内容的提问来源于stack exchange，提问作者David Shepard
相关产品推荐
相关产品推荐
