這個(gè)標(biāo)題里的現(xiàn)象我印象太深了。之前幫朋友排查一個(gè)部署在 Windows Server 上的 .NET Core 項(xiàng)目項(xiàng)目里掛了 SignalR 做實(shí)時(shí)通知結(jié)果只要在線客戶端數(shù)量到 10 個(gè)左右Web API 的請求就全部卡住轉(zhuǎn)圈轉(zhuǎn)到超時(shí)。一開始我還以為是代碼里有死鎖后來才發(fā)現(xiàn)問題出在 IIS、SignalR 和 ASP.NET Core 并發(fā)模型這三者的配合上。如果你也遇到類似情況建議先別急著改業(yè)務(wù)代碼這篇文章我會把整個(gè)排查過程和解決方案拆開講清楚為什么 10 個(gè)連接會成為臨界點(diǎn)、怎么確認(rèn)當(dāng)前 SignalR 到底走的什么傳輸模式、IIS 上需要做什么配置以及代碼里哪些隱藏坑會直接放大這個(gè)問題。1. 故障現(xiàn)象與問題定位1.1 現(xiàn)象描述在線連接數(shù)一到 10 個(gè)左右API 全部轉(zhuǎn)圈先還原一下現(xiàn)場。項(xiàng)目是標(biāo)準(zhǔn)的前后端分離架構(gòu)后端是 ASP.NET Core Web API部署在 Windows Server 的 IIS 上前端通過 SignalR 客戶端接收服務(wù)端推送的消息。項(xiàng)目剛發(fā)布時(shí)一切正常但運(yùn)行一段時(shí)間后只要 SignalR 的在線連接數(shù)達(dá)到 10 個(gè)左右再發(fā)起任何一個(gè) Web API 請求瀏覽器端就會一直處于 pending 狀態(tài)直到 IIS 返回 504 或 503。這個(gè)現(xiàn)象有幾個(gè)非常明顯的特征SignalR 連接本身沒有立刻斷開客戶端顯示已連接。新的 HTTP 請求進(jìn)不來但已經(jīng)建立的連接還能維持一段時(shí)間。重啟 IIS 應(yīng)用程序池之后系統(tǒng)短暫恢復(fù)但連接數(shù)再次上來后又開始卡。卡住的時(shí)間不固定有時(shí)幾十秒有時(shí)直接超時(shí)。這種“連接數(shù)一到某個(gè)量級就整體阻塞”的現(xiàn)象很容易讓人誤判成數(shù)據(jù)庫連接池耗盡或者某個(gè) Redis 連接問題。但仔細(xì)觀察會發(fā)現(xiàn)即使是不查數(shù)據(jù)庫的靜態(tài)接口也卡住說明問題出在更底層的 HTTP 請求處理鏈路上而不是某個(gè)具體業(yè)務(wù)模塊。1.2 最先想到的檢查項(xiàng)排除死鎖和接口慢查詢遇到這種問題我第一反應(yīng)是排查代碼里有沒有同步阻塞比如在 async 方法里用了 .Result 或者 .Wait()。因?yàn)?SignalR 的 Hub 方法和 Web API 是跑在同一個(gè)進(jìn)程里的如果某個(gè) Hub 方法里有同步阻塞調(diào)用線程池線程會被快速耗盡新請求自然進(jìn)不來。我先做了三件事用日志記錄每個(gè)請求的進(jìn)入時(shí)間和離開時(shí)間看是根本沒進(jìn)來還是進(jìn)來了但處理很慢。把數(shù)據(jù)庫、Redis 等外部依賴全部暫時(shí)屏蔽測一個(gè)純內(nèi)存返回的接口看是否還會卡。檢查所有 Service 注冊的生命周期確認(rèn)沒有把 DbContext 這種 Scoped 服務(wù)錯(cuò)誤注冊成 Singleton導(dǎo)致并發(fā)競爭。結(jié)果出乎意料純內(nèi)存接口在連接數(shù)上來之后照樣卡。也就是說問題不在這幾個(gè)常見坑里而是 IIS 和 SignalR 之間的請求處理方式出了問題。1.3 明確的排查方向SignalR 的傳輸模式當(dāng)排除了業(yè)務(wù)代碼后我把目光放到了 SignalR 的傳輸機(jī)制上。SignalR 為了兼容不同環(huán)境默認(rèn)支持三種傳輸方式WebSocket、Server-Sent EventsSSE、Long Polling。這里有一個(gè)很關(guān)鍵的知識點(diǎn)并不是所有部署環(huán)境都能真正走 WebSocket。SignalR 客戶端啟動時(shí)會先發(fā)一個(gè) negotiate 請求然后根據(jù)服務(wù)器返回的能力和當(dāng)前網(wǎng)絡(luò)環(huán)境選擇最優(yōu)傳輸方式。如果 IIS 上沒裝 WebSocket Protocol 功能或者中間有代理/負(fù)載均衡器沒有正確轉(zhuǎn)發(fā) Upgrade 頭SignalR 就會自動回退到 SSE 或 Long Polling。而 SSE 和 Long Polling 有一個(gè)致命問題每一個(gè)在線客戶端都會長期占住一個(gè) HTTP 請求不釋放。服務(wù)端處理這些請求需要占用線程或異步連接當(dāng)連接數(shù)量達(dá)到一定臨界值后剩余的處理能力就無法響應(yīng)新的 API 請求了。這就解釋了為什么看起來像是“10 個(gè)連接之后開始阻塞”——實(shí)際上這取決于服務(wù)器配置的并發(fā)上限、CPU 核數(shù)、線程池初始線程數(shù)等因素10 只是一個(gè)常見臨界值。2. 為什么 10 個(gè)連接就能把請求堵死核心原理拆解2.1 IIS 托管 .NET Core 的請求處理模型要理解阻塞的根因必須先知道 .NET Core 應(yīng)用發(fā)布到 IIS 后請求是怎么流動的。當(dāng)前主流的部署方式是進(jìn)程內(nèi)托管In-Process也就是說 ASP.NET Core 應(yīng)用直接跑在 IIS 的應(yīng)用程序池工作進(jìn)程里IIS 接收到 HTTP 請求后直接交給應(yīng)用內(nèi)的 Kestrel 服務(wù)器處理不再經(jīng)過一個(gè)獨(dú)立的 Kestrel 進(jìn)程。進(jìn)程內(nèi)托管的好處是性能更好少一次進(jìn)程間通信。但它也意味著應(yīng)用和 IIS 共享同一個(gè)進(jìn)程的資源包括線程池。IIS 本身對并發(fā)請求是有隊(duì)列管理的應(yīng)用程序池有一個(gè)“隊(duì)列長度”參數(shù)默認(rèn)是 1000。也就是說如果請求處理不過來新請求會在 IIS 隊(duì)列里排隊(duì)而不是直接進(jìn)到應(yīng)用代碼里。但這里要注意IIS 的隊(duì)列長度默認(rèn) 1000理論上不會在 10 個(gè)連接時(shí)就爆掉。真正的瓶頸出現(xiàn)在 ASP.NET Core 的線程池和 SignalR 連接模型之間的沖突上。2.2 SignalR 的三種傳輸方式與連接占用差異SignalR 的三種傳輸方式對連接資源的占用是完全不同的WebSocket一次 HTTP 握手后協(xié)議升級為長連接數(shù)據(jù)雙向?qū)崟r(shí)傳輸。這種連接不占用 HTTP 請求處理線程對服務(wù)器壓力最小。Server-Sent Events服務(wù)器向客戶端單向推送客戶端通過 EventSource 接收。服務(wù)器會保持一個(gè) HTTP 響應(yīng)連接長期不關(guān)閉每個(gè)客戶端占一個(gè)請求槽。Long Polling客戶端發(fā)一個(gè)請求服務(wù)器有消息就立即返回沒消息就掛住等有消息或超時(shí)后再返回客戶端收到后立刻發(fā)起下一個(gè)請求。這種模式下每個(gè)客戶端在任何時(shí)刻也至少會有一個(gè)掛起的 HTTP 請求。麻煩就出在后兩種模式。如果 SignalR 因?yàn)槟撤N原因沒有升級到 WebSocket而是回退到了 SSE 或 Long Polling那么每一個(gè)在線客戶端就相當(dāng)于一個(gè)永不結(jié)束的 HTTP 請求。在 ASP.NET Core 中這種長時(shí)間掛起的請求會占用線程池的可用線程。雖然異步請求不會一直占著線程不放但 SignalR 在處理消息調(diào)度、連接生命周期等邏輯時(shí)仍然需要線程池分配線程來執(zhí)行回調(diào)。一旦這種半掛起的任務(wù)數(shù)量多了線程池就會進(jìn)入“饑餓”狀態(tài)。2.3 線程池饑餓真正壓垮系統(tǒng)的最后一根稻草.NET 的線程池有一個(gè)動態(tài)調(diào)節(jié)機(jī)制。它會根據(jù)任務(wù)的到達(dá)速率和完成速率自動增加或減少線程數(shù)。增加線程是有成本的需要消耗 CPU 和內(nèi)存所以線程池有一定的“惰性”。當(dāng)任務(wù)量突然增大且部分任務(wù)長時(shí)間不完成時(shí)線程池會嘗試每 500 毫秒左右增加一個(gè)線程。聽起來好像問題不大但如果你的 SignalR 連接模式是 SSE 或 Long Polling這些連接會把線程池的“活躍請求數(shù)”撐起來但每個(gè)請求都不結(jié)束。線程池判斷系統(tǒng)仍然繁忙于是不斷加線程直到線程數(shù)達(dá)到上限。而線程數(shù)到達(dá)上限后新進(jìn)來的 API 請求會進(jìn)入線程池的全局隊(duì)列。上面說的是理論上最典型的情況還有一個(gè)容易被忽略的技術(shù)細(xì)節(jié)線程池的“最小線程數(shù)”。默認(rèn)情況下.NET 線程池的最小線程數(shù)通常等于 CPU 核心數(shù)。如果一個(gè)部署環(huán)境是 4 核甚至 2 核那么最小線程數(shù)很低一旦連接數(shù)稍微上來一點(diǎn)線程池就很容易進(jìn)入饑餓策略。實(shí)際上線程池饑餓時(shí)不一定真的加不上線程而是加線程的速度趕不上請求堆積的速度。加上很多開發(fā)者在 Hub 方法里習(xí)慣性地寫了同步代碼比如用 HttpClient 的 .Result、用 Thread.Sleep、用 lock(obj)這會讓線程被真正占用而不是異步掛起進(jìn)一步加速線程池耗盡。2.4 為什么臨界點(diǎn)看起來是“10 個(gè)連接”而不是其他數(shù)字很多人在排查時(shí)會糾結(jié)“為什么是 10”甚至去 IIS 配置里找有沒有哪項(xiàng)限制是 10。我排查過不少案例得出的結(jié)論是10 并不是 IIS 寫死的數(shù)字而是你的服務(wù)器資源、線程池配置和應(yīng)用代碼共同決定的臨界值?？梢宰鲆粋€(gè)簡單推算假設(shè)服務(wù)器 CPU 是 2 核線程池默認(rèn)最小線程數(shù)可能就是 2。當(dāng)有 10 個(gè) SignalR 客戶端在線且每個(gè)客戶端因?yàn)閭鬏斈Ｊ交赝硕急３种粋€(gè) SSE 或 Long Polling 請求這時(shí)候線程池里至少有 10 個(gè)長期掛起的異步操作。如果其中一部分 Hub 方法還做了同步阻塞調(diào)用那么真正能用來處理新請求的線程可能已經(jīng)所剩無幾。新請求進(jìn)來后排隊(duì)等待表現(xiàn)得就像被“阻塞”了一樣。所以重點(diǎn)不是去找一個(gè)隱藏的 10 連接上限而是先確認(rèn)你的 SignalR 在 IIS 上到底走了哪種傳輸模式如果走的是 WebSocket10 個(gè)長連接根本不叫事如果走的是 SSE 或 Long Polling50 個(gè)、100 個(gè)連接遲早會暴露問題。2.5 另一個(gè)隱藏因素ASP.NET Core 版本和托管模式差異不同版本的 ASP.NET Core 在 IIS 上的并發(fā)行為也有差別。比如 .NET Core 3.1 到 .NET 6、.NET 8雖然整體模型一致但在 ThreadPool 的默認(rèn)策略和 ANCM 的轉(zhuǎn)發(fā)細(xì)節(jié)上會有微調(diào)。另外如果你的部署選擇了進(jìn)程外托管Out-Of-Process請求會先經(jīng)過 IIS再由 ANCM 轉(zhuǎn)發(fā)給獨(dú)立的 Kestrel 進(jìn)程。這種模式下IIS 和 Kestrel 之間有額外的進(jìn)程間通信開銷同時(shí) IIS 的一些機(jī)制可能會在傳輸升級時(shí)產(chǎn)生額外的握手消耗也會影響連接臨界值。如果你不確定自己項(xiàng)目是進(jìn)程內(nèi)還是進(jìn)程外托管最簡單的方法是看 web.config 里的 aspNetCore 節(jié)點(diǎn)。hostingModelinprocess 就是進(jìn)程內(nèi)hostingModeloutofprocess 就是進(jìn)程外。3. 排查實(shí)錄從復(fù)現(xiàn)到定位的完整過程3.1 第一步復(fù)現(xiàn)問題并確認(rèn)連接方式和數(shù)量排查任何這類問題復(fù)現(xiàn)是第一位的。我寫了一個(gè)簡單的 SignalR 客戶端模擬器循環(huán)創(chuàng)建 30 個(gè)連接連接到目標(biāo) Hub。每建立一個(gè)連接就調(diào)用一次 Web API觀察是否出現(xiàn)阻塞。復(fù)現(xiàn)的同時(shí)在瀏覽器開發(fā)者工具里查看 SignalR 的 negotiate 請求和后續(xù)請求協(xié)議。如果能看到 101 Switching Protocols說明走的是 WebSocket。如果看不到而是一直有狀態(tài)為 pending 的 GET 請求那基本可以確定走的是 SSE 或 Long Polling。如果項(xiàng)目是 C# 客戶端還可以在 HubConnectionBuilder 里直接指定傳輸方式來做對照試驗(yàn)var connection new HubConnectionBuilder() .WithUrl(https://your-server/notificationHub, options { options.Transports HttpTransportType.WebSockets; options.SkipNegotiation true; }) .WithAutomaticReconnect() .Build();注意SkipNegotiation 只有在你明確使用 WebSocket 傳輸時(shí)才可以使用。如果服務(wù)器端不支持 WebSocket這種寫法會直接拋異常而不是自動回退。這在排查時(shí)非常有用如果指定了 WebSocket 后全部連接失敗說明問題就出在 WebSocket 握手鏈路不通。我在那個(gè)項(xiàng)目里做了同樣的驗(yàn)證發(fā)現(xiàn)客戶端指定 WebSocket 傳輸后連接全部失敗。再回頭查 IIS 功能果然WebSocket Protocol 沒有安裝。問題到這里已經(jīng)鎖定了八成。3.2 第二步檢查 IIS 的 WebSocket Protocol 功能Windows Server 上 IIS 默認(rèn)不會安裝所有功能模塊。WebSocket Protocol 屬于“應(yīng)用程序開發(fā)”類別下的一個(gè)子功能如果在安裝 IIS 時(shí)沒有手動勾選默認(rèn)是缺失的?？梢杂?PowerShell 檢查當(dāng)前是否安裝了 WebSocket ProtocolGet-WindowsFeature Web-WebSockets如果 Installed 狀態(tài)是 False說明 IIS 缺少 WebSocket 支持。安裝命令也很簡單Install-WindowsFeature Web-WebSockets安裝完成后建議重啟 IISiisreset這里有一個(gè)容易踩的坑WebSocket Protocol 的安裝可能需要重啟服務(wù)器或者至少重啟 IIS 服務(wù)才能生效。如果只裝了功能不重啟SignalR 握手仍然可能失敗。3.3 第三步用 dotnet-counters 觀察線程池狀態(tài)為了拿到更直接的數(shù)據(jù)我使用了 dotnet-counters 這個(gè)診斷工具。如果你的服務(wù)器上還沒裝可以先安裝dotnet tool install --global dotnet-counters然后找到應(yīng)用進(jìn)程 ID開始監(jiān)控線程池和 CPU 狀態(tài)dotnet-counters monitor --process-id PID --counters System.Runtime重點(diǎn)關(guān)注這幾個(gè)指標(biāo)ThreadPool Thread Count線程池當(dāng)前線程數(shù)、ThreadPool Queue Length線程池隊(duì)列長度、CPU UsageCPU 使用率。在復(fù)現(xiàn)阻塞時(shí)觀察到的現(xiàn)象往往是線程池線程數(shù)在不停上漲但隊(duì)列長度也在增長CPU 使用率卻不高。這說明系統(tǒng)不是忙到算不過來而是有大量線程被“卡住”了典型特征就是線程饑餓。如果 ThreadPool Queue Length 持續(xù)高于 0而 Thread Count 已經(jīng)達(dá)到一個(gè)較高值比如幾百幾乎可以斷定代碼或信號連接中存在著長時(shí)間占用線程的操作。3.4 第四步開啟 stdout 日志確認(rèn) ANCM 的報(bào)錯(cuò)信息在 IIS 上排查 ASP.NET Core 問題一個(gè)很大的困惑是應(yīng)用崩潰或連接異常時(shí)錯(cuò)誤信息不會直接顯示在瀏覽器里而是被 ANCMASP.NET Core Module吞掉了。這時(shí)候可以臨時(shí)開啟 stdout 日志來看 ANCM 層面的錯(cuò)誤。在 web.config 中修改 aspNetCore 節(jié)點(diǎn)aspNetCore processPathdotnet arguments.\YourApp.dll stdoutLogEnabledtrue stdoutLogFile.\logs\stdout hostingModelinprocess environmentVariables environmentVariable nameASPNETCORE_ENVIRONMENT valueDevelopment / /environmentVariables /aspNetCore注意保存 web.config 后 IIS 會自動重啟應(yīng)用這個(gè)特性有時(shí)候很貼心有時(shí)候也會造成連接閃斷。開啟日志后讓問題復(fù)現(xiàn)一次再去 logs 目錄下查看最新的 stdout 日志。日志里可能不會直接寫“WebSocket 不可用”但往往能看到連接被拒絕或升級失敗的相關(guān)記錄。另外如果你有 Failed Request Tracing 的權(quán)限也可以配置一條跟蹤規(guī)則專門監(jiān)聽 HTTP 500 和 HTTP 502 請求能夠看到更詳細(xì)的內(nèi)部錯(cuò)誤鏈。對于長期運(yùn)行的生產(chǎn)環(huán)境我建議在 Web.config 里保留 stdoutLogEnabledfalse改成按需開啟避免日志文件暴漲占用磁盤空間。3.5 第五步查看應(yīng)用池的隊(duì)列長度與回收策略如果 WebSocket 已經(jīng)安裝了、代碼也確認(rèn)沒有明顯的同步阻塞問題仍然存在那就要看 IIS 應(yīng)用程序池的配置了。在 IIS 管理器中右鍵應(yīng)用程序池選擇“高級設(shè)置”會看到幾個(gè)關(guān)鍵參數(shù)隊(duì)列長度Queue Length默認(rèn) 1000。如果請求堆積超過這個(gè)數(shù)IIS 會直接返回 503。最大工作進(jìn)程數(shù)Maximum Worker Processes默認(rèn) 1。如果你的應(yīng)用配置成了多個(gè)需要額外注意會話一致性和 SignalR 跨進(jìn)程消息的問題。SignalR 默認(rèn)是無粘性的多個(gè)進(jìn)程時(shí)需要用 Redis Backplane 之類的方式同步消息?；厥諘r(shí)間Regular Time Interval默認(rèn) 1740 分鐘即 29 小時(shí)。但如果你在代碼里手動調(diào)用了 GC.Collect 或某些特殊操作應(yīng)用池回收也會造成連接全斷。對于 SignalR 場景不要在應(yīng)用池上開啟“重疊回收”因?yàn)?SignalR 連接在回收期間會全部斷開客戶端雖然會自動重連但會產(chǎn)生一次明顯的消息丟失窗口。合理的做法是把應(yīng)用池回收時(shí)間改到凌晨低峰期或者設(shè)置成根據(jù)虛擬內(nèi)存/私有內(nèi)存使用量來回收。3.6 第六步代碼里的靜態(tài)全局狀態(tài)排查線程池饑餓還有一個(gè)不太容易察覺的原因SignalR Hub 中使用了靜態(tài)變量或靜態(tài)集合并且沒有加鎖。比如一個(gè)在線用戶列表如果是用靜態(tài) Dictionary 維護(hù)多個(gè)連接同時(shí)寫入時(shí)會造成競爭。下面這種寫法在并發(fā)下很危險(xiǎn)public class NotificationHub : Hub { private static readonly Dictionarystring, string _connections new(); public override async Task OnConnectedAsync() { _connections[Context.ConnectionId] Context.UserIdentifier; await base.OnConnectedAsync(); } }如果寫入時(shí)沒有線程安全的保護(hù)可能在低并發(fā)時(shí)沒問題但到一定并發(fā)量后觸發(fā)內(nèi)部哈希碰撞或擴(kuò)容問題導(dǎo)致請求卡住。這個(gè)和 IIS 無關(guān)但會疊加在 SignalR 的并發(fā)問題上讓系統(tǒng)看起來更早到達(dá)臨界點(diǎn)。建議要么使用 ConcurrentDictionary要么給字典操作加鎖。這里用 ConcurrentDictionary 就行private static readonly ConcurrentDictionarystring, string _connections new();排查這一步時(shí)可以在靜態(tài)變量的寫入邏輯處加日志觀察阻塞發(fā)生時(shí)這些靜態(tài)操作是否耗時(shí)異常。4. 解決方案從 IIS 配置到代碼改造的完整落地4.1 優(yōu)先保證 SignalR 走 WebSocket而不是降級到 SSE解決這個(gè)問題的第一優(yōu)先級是讓 SignalR 盡可能使用 WebSocket。只要傳輸模式是 WebSocket就不會出現(xiàn)“每個(gè)客戶端占住一個(gè) HTTP 請求”的情況后面講的很多配置優(yōu)化才真正有意義。服務(wù)端確保支持 WebSocket 的代碼很簡單。在 Program.cs 或 Startup.cs 中需要顯式調(diào)用 UseWebSocketsvar builder WebApplication.CreateBuilder(args); builder.Services.AddSignalR(); var app builder.Build(); app.UseWebSockets(); app.MapHubNotificationHub(/notificationHub); app.Run();這里有一個(gè)順序問題UseWebSockets 必須放在 UseRouting 之后、MapHub 之前調(diào)用同時(shí)要放在任何可能短路請求的中間件之前比如身份驗(yàn)證中間件通常要放在它之前否則有些請求在驗(yàn)證時(shí)就被攔截了。4.2 安裝并驗(yàn)證 IIS 的 WebSocket 支持前文已經(jīng)提到安裝命令這里再整理一遍圖形化操作路徑打開“服務(wù)器管理器”。點(diǎn)擊“添加角色和功能”。選擇“基于角色或基于功能的安裝”。在“Web 服務(wù)器IIS”下展開“Web 服務(wù)器” - “應(yīng)用程序開發(fā)”。勾選“WebSocket 協(xié)議”。完成安裝后執(zhí)行 iisreset。安裝完成后可以用握手測試確認(rèn) WebSocket 已經(jīng)啟用。最直接的方式是通過瀏覽器的開發(fā)者工具觀察 SignalR 連接是否返回 101 狀態(tài)碼。如果項(xiàng)目不是托管在默認(rèn)站點(diǎn)下而是部署在虛擬目錄或使用 https 協(xié)議要確認(rèn) WebSocket 的升級請求能正常到達(dá)應(yīng)用而不是被 URL Rewrite 等規(guī)則攔截了。4.3 調(diào)整線程池最小線程數(shù)提升系統(tǒng)抗突發(fā)能力即使解決了 WebSocket 支持我仍然不建議跳過線程池優(yōu)化。因?yàn)?SignalR 的消息調(diào)度、心跳檢測、斷線重連等機(jī)制仍然會異步地使用線程池。生產(chǎn)環(huán)境中偶爾的線程池饑餓可能不表現(xiàn)為“10 連接就阻塞”而是表現(xiàn)為“高峰期 CPU 不高但接口響應(yīng)極慢”。可以在應(yīng)用啟動早期調(diào)整線程池最小線程數(shù)。我會在 Program.cs 的 Main 方法最開始處加這樣一段ThreadPool.GetMinThreads(out int workerThreads, out int ioThreads); ThreadPool.SetMinThreads(workerThreads 100, ioThreads 100);這段代碼的意思是把線程池最小工作線程數(shù)和 IO 線程數(shù)各增加 100。這里的 100 不是固定標(biāo)準(zhǔn)值而是根據(jù)實(shí)際并發(fā)量來估算的。如果你的 SignalR 同時(shí)在線連接在 2000 以內(nèi)加 100 已經(jīng)能有效緩解饑餓如果更高建議做壓測來找到更適合的值。但要注意不要一次性把最小線程數(shù)調(diào)得過大比如直接設(shè)成 1000。線程池的最小線程數(shù)決定了系統(tǒng)在請求峰值到來時(shí)能多快創(chuàng)建線程。設(shè)得太大意味著程序一啟動就會創(chuàng)建大量線程白白消耗內(nèi)存設(shè)得太小則在高并發(fā)時(shí)線程池會花時(shí)間慢慢加線程表現(xiàn)為響應(yīng)時(shí)間一路上升。4.4 用配置來強(qiáng)制 SignalR 只走 WebSocket可選方案如果在你的業(yè)務(wù)場景里客戶端環(huán)境完全可控比如是自家公司的內(nèi)部系統(tǒng)、PC 端瀏覽器統(tǒng)一為現(xiàn)代瀏覽器可以考慮強(qiáng)制 SignalR 只使用 WebSocket這樣可以從根上消除 SSE 和 Long Polling 造成的請求占用問題。服務(wù)端在 MapHub 之前加一個(gè)檢查中間件app.Use(async (context, next) { if (context.Request.Path.StartsWithSegments(/notificationHub) !context.WebSockets.IsWebSocketRequest) { context.Response.StatusCode StatusCodes.Status400BadRequest; await context.Response.WriteAsync(WebSocket only.); return; } await next(); });客戶端也需要做對應(yīng)的設(shè)置。在前端 JavaScript 中創(chuàng)建連接時(shí)指定傳輸方式const connection new signalR.HubConnectionBuilder() .withUrl(/notificationHub, signalR.HttpTransportType.WebSockets) .build();如果你看到請求直接返回 400而且服務(wù)端沒有其他日志那基本可以斷定服務(wù)器端不支持 WebSocket需要回過頭檢查 IIS 功能和網(wǎng)絡(luò)代理。這種強(qiáng)制方案的缺點(diǎn)也很明顯如果服務(wù)器前面還有一層負(fù)載均衡器比如 F5、Nginx需要負(fù)載均衡器也支持并放行 WebSocket 的升級請求。很多負(fù)載均衡器默認(rèn)只轉(zhuǎn)發(fā)普通 HTTP對 Upgrade 頭處理不當(dāng)會導(dǎo)致強(qiáng)制 WebSocket 后所有信號連接直接失敗。因此在強(qiáng)制方案前務(wù)必確認(rèn)全鏈路都支持 WebSocket。4.5 如果 WebSocket 不可用退而求其次的調(diào)優(yōu)方案有些團(tuán)隊(duì)的技術(shù)棧限制比較大比如客戶端位于某些安全等級很高的內(nèi)網(wǎng)環(huán)境網(wǎng)關(guān)會屏蔽掉所有非 80/443 端口的協(xié)議升級。這種情況下 WebSocket 可能真的無法使用SignalR 只能長期跑在 SSE 或 Long Polling 下。這時(shí)要做的是盡量減小“每個(gè)連接占一個(gè)請求”的負(fù)面影響?？梢詮膸讉€(gè)方向入手提高 ASP.NET Core 請求隊(duì)列的處理能力也就是合理地增加線程池最小線程數(shù)讓系統(tǒng)在 1000 個(gè)掛起請求時(shí)仍能保持部分線程響應(yīng) API。給 SignalR Hub 方法設(shè)置合理的超時(shí)時(shí)間避免某個(gè)連接長時(shí)間不釋放。將 SignalR 和 Web API 拆分到兩個(gè)不同的應(yīng)用池甚至兩臺服務(wù)器上這樣實(shí)時(shí)連接即使拖垮了 SignalR 應(yīng)用池也不會影響主站 API。拆分方案是我比較推薦的。因?yàn)閺募軜?gòu)上看實(shí)時(shí)推送和 REST API 對資源的占用模型差異很大。實(shí)時(shí)推送是長連接密集型REST API 是短請求密集型。混跑時(shí)長連接容易餓死短請求。分開部署后兩邊可以各自調(diào)優(yōu)互不干擾。4.6 使用進(jìn)程外托管模式減少 IIS 層影響如果你排查了很久發(fā)現(xiàn)是 IIS 層對連接升級或請求隊(duì)列的處理有問題而你的項(xiàng)目又恰好是進(jìn)程內(nèi)托管可以考慮切換為進(jìn)程外托管。進(jìn)程外托管的優(yōu)勢在于ASP.NET Core 應(yīng)用跑在獨(dú)立的 Kestrel 進(jìn)程中IIS 只作為反向代理。這種模式下請求在 IIS 和 Kestrel 之間多了一次轉(zhuǎn)發(fā)單請求性能會略降但隔離性更好。如果你的應(yīng)用本身沒有性能瓶頸只是被 IIS 的某些連接管理機(jī)制拖住這種隔離可能會讓問題消失。修改 web.configaspNetCore processPathdotnet arguments.\YourApp.dll stdoutLogEnabledfalse hostingModeloutofprocess /aspNetCore進(jìn)程外托管模式下SignalR 連接的實(shí)際承載者是 KestrelIIS 只負(fù)責(zé)將升級后的 WebSocket 流量透明轉(zhuǎn)發(fā)。在 Windows 的 HTTP.sys 層這種轉(zhuǎn)發(fā)的處理效率和穩(wěn)定性通常比進(jìn)程內(nèi)更好。缺點(diǎn)是進(jìn)程外模式會額外占用一個(gè)進(jìn)程的內(nèi)存部署結(jié)構(gòu)相對復(fù)雜一些。5. 常見問題與避坑經(jīng)驗(yàn)速查表5.1 連接數(shù)到臨界點(diǎn)就整體卡死懷疑是 IIS 限制現(xiàn)象可能原因處理方法連接數(shù)到 10-20 之后就阻塞SignalR 走 SSE/Long Polling占滿線程池安裝 WebSocket Protocol讓 SignalR 升級為 WebSocket純內(nèi)存 API 也卡死CPU 卻不高線程池饑餓調(diào)大線程池最小線程數(shù)檢查 Hub 內(nèi)同步阻塞代碼瀏覽器 Network 里沒有看到 101 狀態(tài)碼WebSocket 握手未完成檢查 IIS 功能、反向代理的 Upgrade 頭配置請求直接返回 503應(yīng)用池隊(duì)列長度超限或應(yīng)用無響應(yīng)檢查應(yīng)用池隊(duì)列長度確認(rèn)應(yīng)用池未頻繁回收指定 WebSocket 傳輸后連接全失敗服務(wù)器端不支持 WebSocket確認(rèn) Web-WebSockets 功能已安裝5.2 SignalR 斷線自動重連時(shí)的隱藏坑SignalR 的自動重連機(jī)制在客戶端斷線后會以指數(shù)退避的方式嘗試重新連接。每次重連都會重新發(fā)起 negotiate 請求如果客戶端量非常大重連風(fēng)暴造成的瞬時(shí)并發(fā)會對服務(wù)器造成巨大壓力。我曾見過一個(gè)項(xiàng)目因?yàn)榘胍拱l(fā)布導(dǎo)致所有連接斷開客戶端默認(rèn)配置在斷開后 0 秒、2 秒、10 秒、30 秒等時(shí)間點(diǎn)集中重連。當(dāng)時(shí)同時(shí)在線約 5000 個(gè)客戶端重連風(fēng)暴直接把 API 打垮。后來在客戶端加了隨機(jī)延遲const connection new signalR.HubConnectionBuilder() .withUrl(/notificationHub) .withAutomaticReconnect([0, 1000, 5000, 15000, 30000]) .build();同時(shí)也建議服務(wù)端配置 ClientTimeoutInterval 和 KeepAliveInterval避免服務(wù)端因?yàn)榫W(wǎng)絡(luò)抖動誤殺活躍連接。一個(gè)常見的配置是services.AddSignalR(options { options.ClientTimeoutInterval TimeSpan.FromSeconds(60); options.KeepAliveInterval TimeSpan.FromSeconds(15); options.EnableDetailedErrors true; });5.3 Hub 生命周期與依賴注入的坑ASP.NET Core 的 SignalR Hub 在每次方法調(diào)用時(shí)是瞬時(shí)創(chuàng)建的不是單例。如果你在 Hub 的構(gòu)造函數(shù)里注入了 DbContext而 DbContext 本身是 Scoped這通常沒問題。但如果你在 Hub 里使用了 IHubContext 來從外部推送消息并且這個(gè) IHubContext 被注入到一個(gè) Singleton 服務(wù)中那么在這條調(diào)用鏈上使用 DbContext 就會出問題因?yàn)?Singleton 服務(wù)無法拿到 Scoped 的 DbContext。這種問題在高并發(fā)時(shí)不一定會立刻報(bào)錯(cuò)但當(dāng)連接數(shù)多了以后可能會出現(xiàn)數(shù)據(jù)庫連接被意外釋放或線程阻塞的詭異現(xiàn)象。排查時(shí)可以看看 Hub 中是否有復(fù)雜的依賴鏈如果有盡量讓 Hub 的方法只做消息轉(zhuǎn)發(fā)把業(yè)務(wù)邏輯下沉到獨(dú)立的 Service 中并明確生命周期。5.4 使用反向代理時(shí) WebSocket 升級頭被過濾如果你在 IIS 前面配置了 Nginx、ARR 或其他反代需要確認(rèn)以下請求頭能夠正確傳遞Upgrade: websocket Connection: Upgrade在 Nginx 中針對 WebSocket 的代理需要額外配置 Upgrade 頭。雖然標(biāo)題場景是 IIS但很多企業(yè)網(wǎng)絡(luò)是 IIS 外層還套一個(gè) Nginx 統(tǒng)一入口。這種情況下IIS 本身的 WebSocket 配置正確還不夠外層 Nginx 也得放行。如果你在生產(chǎn)環(huán)境看到“服務(wù)器已安裝 WebSocket 功能但客戶端始終無法升級”的情況大概率就是反代層過濾了 Upgrade 請求頭。5.5 不要忽視 DNS 和負(fù)載均衡層的超時(shí)設(shè)置SignalR 長連接在傳輸層上是保持不關(guān)閉的。很多負(fù)載均衡器默認(rèn)有一個(gè)“空閑連接超時(shí)”比如 60 秒內(nèi)無數(shù)據(jù)傳輸就自動斷開連接。如果 SignalR 的心跳間隔大于這個(gè)超時(shí)時(shí)間連接會被負(fù)載均衡器靜默切斷。客戶端表現(xiàn)為連接斷開隨后自動重連重連成功后再次被切斷形成周期性斷連。解決方法是調(diào)節(jié) SignalR 的心跳頻率或者把負(fù)載均衡器的空閑超時(shí)時(shí)間調(diào)大。服務(wù)端和客戶端都有對應(yīng)的 KeepAlive 配置必須保證心跳間隔小于負(fù)載均衡器的空閑超時(shí)時(shí)長。我建議在部署前先向網(wǎng)絡(luò)團(tuán)隊(duì)確認(rèn)反代層的空閑連接超時(shí)時(shí)間再反推 SignalR 的心跳間隔設(shè)置。6. 最后一次壓測驗(yàn)證與實(shí)際心得解決完全部問題后用壓測工具模擬了 2000 個(gè) SignalR 并發(fā)連接同時(shí)持續(xù)調(diào)用 Web API。這次的現(xiàn)象和之前完全不一樣了API 不會阻塞SignalR 連接也都穩(wěn)定在 WebSocket 狀態(tài)。最初那臺服務(wù)器配置并不高4 核 8GB 內(nèi)存通過合理配置后承載 2000 個(gè)長連接沒有太大壓力?；仡欉@次排查我最大的體會是遇到 IIS .NET Core SignalR 的組合問題不要一上來就懷疑 IIS 版本或框架 bug。90% 的情況是傳輸模式?jīng)]有按預(yù)期走 WebSocket或者代碼中某個(gè)不起眼的同步阻塞放大了并發(fā)問題。下次你再看到“連接數(shù)到 10 個(gè)就卡死”這類描述第一件事就去確認(rèn)瀏覽器 Network 面板里有沒有 101 Switching Protocols。如果始終沒有那跟線程池較勁沒意義先把 WebSocket 的握手鏈路打通再說。SignalR 本身的設(shè)計(jì)是支持大規(guī)模長連接的IIS 上要做的只是把這條通道正確建起來別讓它降級到 HTTP 輪詢模式去硬扛。