{"id":844,"date":"2026-10-06T22:11:59","date_gmt":"2026-10-06T22:11:59","guid":{"rendered":"https:\/\/windows-vps.org\/blog\/?p=844"},"modified":"2026-10-06T22:11:59","modified_gmt":"2026-10-06T22:11:59","slug":"iis-websocket-signalr-connection-limits-windows-server","status":"publish","type":"post","link":"https:\/\/windows-vps.org\/blog\/iis-websocket-signalr-connection-limits-windows-server\/","title":{"rendered":"IIS WebSocket vs SignalR Connection Limits on Windows Server"},"content":{"rendered":"\n

Real-time features — chat, dashboards, notifications, live collaboration — all need a persistent connection, and on Windows Server that means WebSockets. Once you move past a demo, the questions change: how many concurrent sockets can IIS hold, what does SignalR change, and where does the ceiling actually sit? This article covers the architecture, the tuning knobs, and the limits that bite in production, so you can size an instance against reality rather than guesswork.<\/p>\n\n\n\n

How IIS Handles WebSockets<\/h2>\n\n\n\n

IIS supports WebSockets through the WebSocket Protocol feature, which runs inside the request pipeline and hands the upgraded connection to the application pool worker process. Each open socket consumes a worker thread only while actively processing, but it holds memory, a connection slot, and kernel-side state for as long as it lives. Two limits govern scale: the connection limits of the Windows HTTP stack (Http.sys) and the resources of the worker process itself.<\/p>\n\n\n\n

The upgrade itself is an ordinary HTTP request that asks to switch protocols. If the feature is not installed, the request simply stays a normal HTTP connection and the real-time layer silently fails over — or breaks. Confirm the feature is present before debugging anything else: Get-WindowsOptionalFeature -Online -FeatureName IIS-WebSockets<\/code> should report Enabled on a host that fronts a real-time app.<\/p>\n\n\n\n

SignalR Does Not Replace the Transport — It Manages It<\/h2>\n\n\n\n

ASP.NET Core SignalR is an abstraction: it picks the best available transport at runtime, preferring WebSockets and falling back to Server-Sent Events or long polling when sockets are unavailable. That fallback matters on a VPS behind a proxy that strips the upgrade header, but it also means your server must handle all three modes. The practical difference:<\/p>\n\n\n\n

Concern<\/th>Raw WebSockets<\/th>SignalR<\/th><\/tr><\/thead>
Protocol handling<\/td>You write it<\/td>Built in<\/td><\/tr>
Fallback transport<\/td>None<\/td>SSE \/ long polling<\/td><\/tr>
Connection tracking<\/td>Manual<\/td>Hubs and groups<\/td><\/tr>
Scale-out<\/td>Custom backplane<\/td>Redis or Azure SignalR<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The fallback modes are more expensive per client than a socket, because long polling opens repeated short requests. A server sized for 5,000 WebSocket clients may handle far fewer if the proxy forces long polling. Always test with the transport you will actually get, not the one you hope for.<\/p>\n\n\n\n

The Real Limits and How to Tune Them<\/h2>\n\n\n\n