Last post Oct 08, 2013 04:17 PM by xsov
Oct 08, 2013 06:56 AM|xsov|LINK
We have a fixed high rate messages from the server to a number of web socket client connections on different machines via PersistentConnection. Any given message is unique and is only sent to one client connection. The message generator/frequency controller
uses very few resources (< 2% CPU, a few MB RAM). It has been tested thoroughly using a stand-in streaming framework.
For 3.000 connections and a message rate of 20Hz (i.e. a throughput of 60.000 messages per second, which is the maximum achievable on that particular server because it hits a CPU limit) we see latencies distributed from 0-50ms with an average about 20-25ms.
For lower throughputs (300 connections at 20Hz) we observe average latencies from 0-3ms. We aim for latencies below 5ms, and it seems that we hit that limit with a throughput of about 5.000-10.000 messages per second.
For these kinds of setups there seems to be a trade-off between the maximum achievable throughput and the message latency, e.g. due to send buffering on the underlying socket. We would like to optimize SignalR for minimum latency even at the cost of the
maximum achievable throughput (the 60.000 messages per second), but would still like to raise the throughput above 5.000-10.000 messages per second.
What would you generally do to optimize for low latency in SignalR?
Oct 08, 2013 03:30 PM|gustavo_armenta|LINK
Oct 08, 2013 03:31 PM|abhishek.nanda|LINK
Information about SignalR performance and scaling can be found here : http://www.asp.net/signalr/overview/performance-and-scaling
Have you considered using SignalR scaleout with multiple servers to reduce the latency?
Oct 08, 2013 04:17 PM|xsov|LINK
Thanks for your answer. Scaleout is planned, but we would like to be able to deliver more than 5.000-10.000 messages per second from each server, which is what one server can handle within the latency limit of 5ms.
As for the performance guide, we cannot reduce the message size, all the settings in the guide have been implemented, we are using web sockets, and throttling is handled at the message source.