Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

SignalR / Websockets connection limitations and best practices

I'm trying to understand how to best design an IIS/ASP.NET based websocket application, specifically regarding concurrency limitations.

I've read all the literature on IIS/ASP.NET regarding "concurrent Websocket connections" and how to tweak the various values - however, when speaking about websockets, what is the definition of "concurrent"? If I have opened a websocket and its sitting idle, is that "using" a connection? Do idle websockets count towards connection usage totals, or does it only count when a message is being sent/received?

I expect to have a very high (100s of thousands) number of websockets open at any one time, however there will be very few messages sent, perhaps a few per minute and they will always be server->client (and to a single, specific client, not a broadcast). Does/should this arrangement lead me down any particular implementation route?

It seems SignalR hubs are probably overkill, I don't need fallbacks for clients that dont support websockets and I only need to maintain a handle on the each clients connection, such that when my system "decides" to send a message to a particular client, it can route it appropriately.

Docs I'm referencing:

  • https://github.com/SignalR/SignalR/wiki/Performance
  • http://www.asp.net/signalr/overview/performance/scaleout-in-signalr

Thanks

like image 954
Andrew Bullock Avatar asked Jul 28 '15 19:07

Andrew Bullock


People also ask

Would WebSockets be able to handle 1000000 concurrent connections?

With at least 30 GiB RAM you can handle 1 million concurrent sockets.

Does SignalR require WebSockets?

SignalR uses Web socket technology to send data. WebSocket is a new HTML5 API that enables bidirectional communication between the browser and server but if it is not available then SignalR can use other technologies like long polling.

How long does a SignalR connection last?

The default keepalive timeout period is currently 20 seconds. If your client code tries to call a Hub method while SignalR is in reconnecting mode, SignalR will try to send the command. Most of the time, such attempts will fail, but in some circumstances they might succeed.


1 Answers

however, when speaking about websockets, what is the definition of "concurrent"? If I have opened a websocket and its sitting idle, is that "using" a connection? Do idle websockets count towards connection usage totals, or does it only count when a message is being sent/received?

Right, a open connection sitting idle does not consume much resources beyond TCP keep-alives and maybe protocol and/or application level ping/pongs if your server supports them. More importantly, as Websockets are connection oriented you may be holding some state associated with the connection as well (an user object, user data, etc...)

I expect to have a very high (100s of thousands) number of websockets open at any one time, however there will be very few messages sent, perhaps a few per minute and they will always be server->client (and to a single, specific client, not a broadcast). Does/should this arrangement lead me down any particular implementation route?

Yes, to the route of not using SignalR: SignalR Scale-out (check the limitations section). Use WebSockets directly and implement your own messaging back-end with a framework that allows smart routing like RabbitMQ for example. You don´t want to use a backplane that is basically doing "fan-out" to all nodes, especially if the data is per user.

SignalR is a polyfill, a transient framework until the day WebSockets are broadly supported... and that already happened. Also forgot to mention that WebSockets are available from Windows server 2012 onwards :)

like image 169
vtortola Avatar answered Sep 28 '22 05:09

vtortola