Scaling out with SQL Server

The SignalR team provides a third backplane option, based on Microsoft SQL Server. This one could be a good fit if both Windows Azure and Redis are not an option for you. It has good resilience characteristics, although it's not the best option in terms of performance.

In this recipe, we'll assume you have a SQL Server instance available, and we'll see how to plug the SQL Server backplane into a simple application inspired by the previous scale-out recipes.

Getting started

As we did previously, we'll reuse the code we wrote in the recipe about the Windows Azure Service Bus backplane, and we'll just show what's to be different when we add the SQL Server backplane. We'll perform our demonstration using a new empty web application named Recipe40.

In order to correctly support the backplane, we need to perform the following actions:

  1. We need to create an empty database. It does not need to have any special name, and the necessary tables will be created by the backplane itself the first time it's activated.
  2. Our application will run under a specific process account, maybe through impersonation; therefore, we'll have to determine the actual identity that will connect to the SQL Server instance and give it the necessary permissions to log in and create tables. The same idea applies if we opt for a SQL Authentication identity. This is necessary just for the first time the backplane connects to the database to create the tables it needs. After that, we could downgrade the permissions we granted to a more traditional read/write set of permissions, or switch to a more adequate user.
  3. Although we will not proceed with this specific step in our discussion, in a production environment it's highly recommended that you enable the SQL Server Service Broker, whose messaging and queuing features greatly enhance the performance of the SQL Server backplane by notifying it directly, in a push fashion, when control messages need to be exchanged. You can check the SQL Server documentation for more details about it, available at http://technet.microsoft.com/en-us/library/bb522893.aspx.

How to do it...

Our sample code will be the same as we wrote for Recipe38; let's quickly review it:

  1. We first add a Hub class called EchoHub and a test page called index.html, whose content will be the same as we had prepared for the previous two recipes.
  2. We then need a Startup class that looks like the following code:
    using Microsoft.Owin;
using Owin;

[assembly: OwinStartup(typeof(Recipe40.Startup))]

namespace Recipe40
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            ...

            app.MapSignalR();
        }
    }
}

    We'll be adding the missing code later when plugging the SQL Server backplane.

We can proceed with a first test pass by opening the index.html page in multiple browser windows and by clicking on the button on each of them to verify that messages are broadcasted across clients. When done, we can proceed by adding the SQL Server backplane using the following steps:

  1. We first need to add the Microsoft.AspNet.SignalR.SqlServer NuGet package to enable support for the SQL Server backplane.
  2. We then go back to the Startup class code, where we first add a using Microsoft.AspNet.SignalR; directive and then the following call just before invoking the MapSignalR() method:
        string connectionString = "[connection string]";
    GlobalHost.DependencyResolver.UseSqlServerSqlServer(connectionString);

    This code is pretty simple: the UseSqlServerSqlServer() method starts the backplane, and we just have to provide the necessary connection string to have access to the database we created earlier.

We are ready to perform a new test on the application by launching it again from Visual Studio in multiple browser windows, and we should not notice any difference from the behavior we observed earlier, with the messages correctly broadcasted across all the clients. You can double-check that the backplane is effectively in place by inspecting the content of the tables in its database.

We can then perform a further test to clearly observe how the backplane works across multiple servers. We open a new command-line window, and from there we launch an instance of IIS Express pointing at our application:

"%programfiles%IIS Expressiisexpress.exe" /path:[path] /port:[port]

As we did in the previous recipe, we are starting a new web server instance that will publish our application: the [path] argument must be the absolute path to the folder of our application, and the [port] value must be a free IP port. When the new IIS Express instance is started, we can open a new browser window pointing at the port we just specified, and a new copy of our test page will be loaded. Regardless of being on a different web server instance, any message sent from here will reach the other windows we opened earlier, and vice versa, thanks to the SQL Server backplane.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset