SignalR has been around for a while now and people are using it to build stunning real-time applications. While this worked fine on a single server deployment, there was no production ready support for running it on a multi server environment (like Windows Azure). A little over a year ago Clemens Vasters released the Windows Azure Service Bus backplane for SignalR which made it possible to deploy SignalR in a web farm. This backplane has been in beta for over a year… but this changed with the release of SignalR 1.1:
In this article we’re going to take the Getting Started sample, make it scalable with the Service Bus backplane and deploy it to a Windows Azure Cloud Service with 4 instances. Let’s get started!
Creating the application
So the first thing I did was create a new Azure project in Visual Studio with a simple ASP.NET Web Role. After that I added the Microsoft.AspNet.SignalR and Microsoft.AspNet.SignalR.ServiceBus packages to the Web Role project:
And after adding the packages I did 2 simple things, creating a hub and creating the “chat page” (this is all based on the Getting Started sample). The hub is very simple, the only thing it includes is the Send method. If you compare this to the original hub in the Getting Started sample you’ll see that I added some extra information to the broadcast: the name of the machine and the ID of the instance. If you’re doing this on-premises you can just remove the last argument.
And the chat page is also fairly simple. I also made some changes to this code to display some info about the instance where the message was sent to (this is the server which sent out the broadcast).
Finally I created a Global.asax file in which I initialized the Service Bus backplane together with the SignalR routing:
As you can see from this code I’m using the CloudConfigurationManager class to get the connection string to my Service Bus namespace. If I’m running in a Windows Azure Cloud Service, the CloudConfigurationManager will get the setting from the Service Configuration (which can be changed after deploying the application). If the application runs as a normal web application (on-premises, in a Windows Azure Web Site, …) it will get the setting from the app/web.config
But before you can get the connection string you’ll need to create a new Service Bus namespace (or get the connection string for an existing namespace).
Service Bus Namespace
Creating a new namespace is easy, simply go to the Windows Azure Portal under Service Bus and press the Create button. After a few seconds the namespace will have been created and you’ll be able to click the Access Key button:
This is where you’ll be able to see the connection string which you can copy to your Service Configuration or to your web.config (depending if you’re deploying to a Cloud Service or not).
Note: Don’t use the owner account in production. Instead, click the Open ACS Management Portal link to create additional Service Identity for that namespace with limited permissions.
Deploy and test
As you can see it was really easy to add the Service Bus backplane. The last thing left to do is deploy the application. I decided to deploy it as a Cloud Service with 4 instances:
And now the only thing I had left to do was to test it out. I opened a few different tabs in IE to make sure that I would be connecting to different instances at the same time.
As you can see I’m sending the chat message to different servers which still manage to broadcast it to all connected clients thanks to the Service Bus backplane. And in the Windows Azure portal you’ll also be able to see that the Service Bus backplane created a topic for your application and a subscription for each instance in your Web Role:
The code for this sample is available on GitHub: https://github.com/sandrinodimattia/WindowsAzure-SignalRScaleOutDemo
Enjoy!