1

I'm still testing SignalR but one of the things that's really important to me is that the messages reach the client as quickly as possible (I'm dealing with real time stock rates).

The things is - under almost every scenario I've tried - from totally local to running 100's of instances on Azure (with back-plane and everything...) , the time it takes the message to get from the server to the client increases exponentially as the number of connected clients increase.

I've tried this with Hubs, Persistent Connection, .net clients, JS clients running in phantomJS, zombieJS & node.js ... I've pretty much tried dozens of configurations, but the behavior is always the same, which leads me to the conclusion that this is something inherent in SignalR.

I know SignalR can handle thousands of concurrent clients on very few servers, but if it takes a couple of seconds for the message to go across (In the same Azure region), it's of no use to me.

Any idea what might be slowing the messages down ?

Thanks

AvnerSo
  • 1,609
  • 1
  • 16
  • 23
  • 1
    Can you provide some details about your scenario? e.g. the number of clients, messages/sec, message size, broadcasting vs. sending to groups/clients/users, connections/server, transports being used, etc. – Damian Edwards Jul 22 '14 at 17:20

1 Answers1

2

It is explained in their scale out guide: http://www.asp.net/signalr/overview/signalr-20/performance-and-scaling/scaleout-in-signalr

Limitations

Using a backplane, the maximum message throughput is lower than it is when clients talk directly to a single server node. That's because the backplane forwards every message to every node, so the backplane can become a bottleneck. Whether this limitation is a problem depends on the application. For example, here are some typical SignalR scenarios:

  • Server broadcast (e.g., stock ticker): Backplanes work well for this scenario, because the server controls the rate at which messages are sent.
  • Client-to-client (e.g., chat): In this scenario, the backplane might be a bottleneck if the number of messages scales with the number of clients; that is, if the rate of messages grows proportionally as more clients join.
  • High-frequency realtime (e.g., real-time games): A backplane is not recommended for this scenario.

So using a backplane will create delays, and depending on the type of application you are doing... it may not be the right choice.

I gave up SignalR long ago and focus on websockets with a proper queuing system behind. You may use a websocket library together with MassTransit for example. SignalR is for little projects, or not very segmented or real time scenarios.

Community
  • 1
  • 1
vtortola
  • 34,709
  • 29
  • 161
  • 263