.NET 6 中使用 SignalR 导致IIS重启后性能骤降问题咨询

可能的框架层面因素 #

• 线程池调度逻辑变更：.NET 6 对线程池的扩容策略、工作线程分配机制做了优化，但当数百个SignalR连接同时触发重连时，可能引发线程池饥饿，导致普通HTTP请求的处理被阻塞。相比.NET 5，.NET 6默认的最小线程数配置更保守，重连高峰阶段无法快速分配足够线程支撑并发请求。
• SignalR重连机制调整：.NET 6 中SignalR的自动重连逻辑（重试间隔、并发连接限制）有更新，若客户端默认无延迟批量重连，短时间内会向服务器发起大量请求，挤占普通请求的资源池。
• IIS集成适配问题：.NET 6的ASP.NET Core模块（ANCM）与IIS的交互逻辑有更新，站点重启后，旧连接的资源可能未被及时清理，导致新连接与残留资源冲突，引发性能瓶颈。

已知相关框架Bug（已修复） #

• 线程池饥饿导致请求阻塞：.NET 6早期版本中，大量异步IO操作（如SignalR WebSocket连接）并发触发时，线程池工作线程分配滞后，普通请求长时间等待。该问题在.NET 6.0.2及后续补丁版本中已修复。
• SignalR连接资源泄漏：部分场景下，站点重启后旧的SignalR连接上下文未被正确释放，占用大量内存与句柄，导致新请求资源不足。该问题在.NET 6.0.5版本中得到修复。

排查与解决步骤 #

1. 升级.NET 6补丁版本：检查当前应用使用的.NET 6具体版本，建议升级至最新补丁版本（至少6.0.2以上），直接排除已知框架Bug。
2. 手动配置线程池参数：在应用启动阶段设置线程池最小线程数，避免重连高峰出现线程饥饿：

   ThreadPool.SetMinThreads(100, 100); // 根据服务器硬件配置调整数值
   

3. 优化客户端重连策略：修改客户端自动重连逻辑，添加随机延迟，避免所有客户端同时发起重连：

   // JavaScript客户端示例
   connection.onclose(async () => {
     await new Promise(resolve => setTimeout(resolve, Math.random() * 5000)); // 0-5秒随机延迟
     await connection.start();
   });
   

4. 调整IIS站点配置：
   • 启用IIS重叠回收（Overlapped Recycle），让新站点实例启动完成后再关闭旧实例，避免连接集中断开重连。
   • 增大应用池的请求队列长度，调整最大工作进程数，确保服务器有足够资源处理并发请求。
5. 性能诊断与监控：
   • 使用dotnet-counters监控线程池状态，确认是否存在线程饥饿：

     dotnet-counters monitor --process-id <进程PID> System.Threading.ThreadPool
     

   • 借助PerfView分析CPU、内存占用，定位资源泄漏或请求阻塞点。
   • 查看IIS请求日志，检查重启后请求的排队时长，确认是否为队列阻塞导致的延迟。

临时缓解方案 #

若暂时无法升级框架版本，可在部署前通过SignalR向客户端发送自定义断开通知，引导客户端分批重连，避免集中冲击服务器。

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