SignalR is the best way to enable real-time communication in modern .NET web applications. So let’s say you have built your first app with SignalR, deployed it to Azure, and everything is working great. After seeing a huge influx of new users, you decide to scale out your App Service to add another instance to handle the extra load. Shortly after, you get complaints from users that the real-time notifications aren’t working, and after debugging it with your team, you find that SignalR is working “about half the time.”
You come to the realization (hopefully, very quickly) that since SignalR runs within the server process, special care must be taken in environments that involve more than one running instance. There are a few different ways to handle a server farm / multiple instance web application with SignalR:
- Sticky Sessions. Referred to as “ARR Affinity” (Application Request Routing Affinity) in Azure App Service, this will keep users “stuck” to the same server instance in a multi-server environment. However, this adds constraints on the load balancing across the instances, and it also prevents you from notifying clients across multiple server instances.
- Redis backplane. SignalR can be configured to use Redis as a backplane to manage clients across multiple server instances. While you can accomplish everything you need to scale SignalR with Redis, it is a more complicated setup and it has its limitations when compared to the third, recommended approach:
- Azure SignalR Service. This is certainly the easiest option to configure and provides the most flexibility. With a few lines of code and setup in Azure, your app can seamlessly delegate the management of SignalR connections to the SignalR Service that will allow you to scale your app without the need to manage how SignalR is hosted.
Azure SignalR Service Configuration
The best part about using Azure SignalR Service is that it is very easy to configure and use. By default, Azure SignalR will use the default configuration key of Azure:SignalR:ConnectionString. You will get this ConnectionString value when you create a new Azure SignalR Service in the Azure Portal. The following ConfigureServices() code will enable SignalR Service in your app with the default ConnectionString key:
public void ConfigureServices(IServiceCollection services)
{
services.AddSignalR()
.AddAzureSignalR();
}
Even though it is only one extra line of code, there is a lot that happens automatically for you. When web clients connect to your existing SignalR Hub, they will be redirected to instead connect to the Azure SignalR Hub. And when your app sends messages to clients, it will automatically route those messages through the Azure SignalR Service.
Azure SignalR Service Cost
The main downside to Azure SignalR Service right now is the current pricing structure. There is a free tier that supports 20 connections per unit and 20,000 messages per day. This is sufficient for a small-scale app or for a development or testing environment, but the free tier connection limit will quickly become a problem with a moderate number of users. The next (and only other) tier is “Standard” which allows 1,000 connections per Unit, up to a maximum 100 Units, and pricing is based on the number of Units, with a minimum of 1 Unit. So while this can scale to a large number of concurrent connections, the lowest possible cost per month is close to $50/month (depending on your Azure region).
There have been calls for consumption-based SignalR Service pricing, which would hopefully lower the cost at the low end and make the pricing much more granular based on the number of concurrent users. It is good to know that David Fowler at Microsoft is aware of this, but no announcements yet on the timing or if this would be added:
Yes we know 😉
— David Fowler 🇧🇧🇺🇸💉💉 (@davidfowl) October 2, 2021
Dynamic Configuration and Cost Sharing
When we use SignalR Service on our Trailhead projects, we often configure it in a way to do two things:
- Allow the application to use either in-process SignalR (for local development and testing) or the hosted SignalR Service, based on configuration, and
- Allow for a SignalR ApplicationName to be set
When you set the ApplicationName property in the AddAzureSignalR() constructor, it allows you to create isolated sets of users (or applications) that can all share the same SignalR Service. If you have multiple applications that need SignalR and each application needs more users than the free tier, but fewer than what the Standard tier provides, you can use the ApplicationName to partition them and share the cost of the Standard tier. And while it is possible to use the same SignalR Service for separate environments (development, testing, production), it is still recommended to use a separate SignalR Service for your production environment. Cost-sharing with ApplicationName still isn’t as good as having a consumption-based pricing model, but until that is available, this can possibly reduce your cost by sharing a single Azure SignalR Service across multiple hosted applications.
Here is the full configuration that will use SignalR in-process if no connection string is set in the configuration (for local testing), and it also allows an ApplicationName to be specified in configuration so you can have multiple applications use the same SignalR ConnectionString, but each set of application users are isolated according to the ApplicationName:
public void ConfigureServices(IServiceCollection services)
{
// Get the SignalR ConnectionString to determine whether to run locally or with Azure SignalR Service
var signalRConnString = Configuration["SignalRConnectionString"];
if (string.IsNullOrEmpty(signalRConnString))
{
// Run SignalR in-process for local development
services.AddSignalR();
}
else
{
// Use Azure SignalR Service with connection string and ApplicationName
services.AddSignalR().AddAzureSignalR(opt =>
{
opt.ConnectionString = signalRConnString;
opt.ApplicationName = Configuration["SignalRAppName"];
});
}
}
