in “ getting started with signalr ," i provided a gentle introduction to signalr with a few simple and practical examples. the overwhelming response showed that i’m not alone in thinking this is an awesome technology enabling real-time push notifications over the web.

web applications often face the challenge of having to scale to handle large amounts of clients, and signalr applications are no exception. in this example, we’ll see one way of scaling out signalr applications using something called a backplane.

scaleout in signalr

“ introduction to scaleout in signalr ” (official documentation) describes how signalr applications can use several servers to handle increasing numbers of clients. when a server needs to push an update, it first pushes it over a message bus called a backplane . this delivers it to the other servers, which can then forward the update to their respective clients.

according to the official documentation, scaleout is supported using azure, redis or sql server as backplanes. third-party packages exist to support other channels, such as signalr.rabbitmq .

scaleout example using redis

“ introduction to scaleout in signalr ” (official documentation) describes how to use signalr as a backplane. to demonstrate this, i’ll build on the chat example code from my “ getting started with signalr ” article.

all we need to scaleout using redis is install the microsoft.aspnet.signalr.redis nuget package, and then set it up in the startup class as follows:

        public void configuration(iappbuilder app)
        {
            globalhost.dependencyresolver.useredis("192.168.1.66", 6379, null, "signalrchat");
            app.mapsignalr();
        }

in the code above, i am specifying the host and port of the redis server, the password (in this case null because i don’t have one), and the name of the pub/sub channel that signalr will use to distribute messages.

to test this, you can get a redis server from the redis download page. redis releases for windows exist and are great for testing stuff, but remember they aren’t officially supported for production environments.

now to actually test it, i’ve set up the same scaleout-enhanced chat application on two different machines, and subscribed to the redis pub/sub channel:

watching the pub/sub channel reveals what signalr is doing under the hood. there are particular messages going through when the application initializes on each machine, and you can also see the actual data messages going through. so when you write a message in the chat, you can also see it in the pub/sub channel.

but even better than that, you’ll also see it on the client (browser) that’s hooked up to the other machine:

the magic you need to appreciate here is that these aren’t two browsers connected to the same server; they are actually communicating with different servers on different machines. and despite that, the messages manage to reach all clients thanks to the backplane, which in this case is redis.

caveats

so i’ve shown how it’s really easy to scale out signalr to multiple servers: you need to install a nuget package and add a line of code. and i’ve actually tested it on two machines.

but that’s not really scaleout. i don’t have the resources to do large-scale testing, and only intended to show how scaleout is implemented with this article. the actual benefits of scaleout depend on the application. as the official documentation warns, the addition of a backplane incurs overhead and can become a bottleneck in some scenarios. you really need to study whether your application is a good fit for this kind of scaleout before going for it.