In general, there are two ways to scale a web application: scale up and scale out.
The problem with scaling up is that you quickly hit a limit on the size of the machine. Beyond that, you need to scale out. However, when you scale out, clients can get routed to different servers. A client that is connected to one server will not receive messages sent from another server.
One solution is to forward messages between servers, using a component called a backplane. With a backplane enabled, each application instance sends messages to the backplane, and the backplane forwards them to the other application instances. (In electronics, a backplane is a group of parallel connectors. By analogy, a SignalR backplane connects multiple servers.)
SignalR currently provides three backplanes:
If you deploy your application on Azure, consider using the Redis backplane using Azure Redis Cache. If you are deploying to your own server farm, consider the SQL Server or Redis backplanes.
The following topics contain step-by-step tutorials for each backplane:
In SignalR, every message is sent through a message bus. A message bus implements the IMessageBus interface, which provides a publish/subscribe abstraction. The backplanes work by replacing the default IMessageBus with a bus designed for that backplane. For example, the message bus for Redis is RedisMessageBus, and it uses the Redis pub/sub mechanism to send and receive messages.
Each server instance connects to the backplane through the bus. When a message is sent, it goes to the backplane, and the backplane sends it to every server. When a server gets a message from the backplane, it puts the message in its local cache. The server then delivers messages to clients from its local cache.
For each client connection, the client’s progress in reading the message stream is tracked using a cursor. (A cursor represents a position in the message stream.) If a client disconnects and then reconnects, it asks the bus for any messages that arrived after the client’s cursor value. The same thing happens when a connection uses long polling. After a long poll request completes, the client opens a new connection and asks for messages that arrived after the cursor.
The cursor mechanism works even if a client is routed to a different server on reconnect. The backplane is aware of all the servers, and it doesn’t matter which server a client connects to.
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:
Systems