Filtered by Tag (redis)
Long time ago (about 5 years, at least), I contributed an article to SignalR wiki about scaling SignalR with Redis. You can still find the article here. I also blogged about it here. However, over time, pictures got lost there. I got a few requests from my readers to refresh those images and I was luckily able to find them :) I decided to publish that article here so that I would have a much better control over the content.
@ 08-08-2018
by Tugberk Ugurlu

Long time ago (about 5 years, at least), I contributed an article to SignalR wiki about scaling a SignalR application with Redis. You can still find the article here. I also blogged about it here. However, over time, pictures got lost there. I got a few requests from my readers to refresh those images and I was lucky enough to be able to find them :) I decided to publish that article here so that I would have a much better control over the content. So, here is the post :)

Please keep in mind that this is a really old post and lots of things have evolved since then. However, I do believe the concepts still resonate and it’s valuable to show the ways of how to achieve this within a cloud provider’s context.

SignalR with Redis Running on a Windows Azure Virtual Machine

This wiki article will walk your through on how you can run your SignalR application in multiple machines with Redis as your backplane using Windows Azure Virtual Machines for scale out scenarios.

Creating the Windows Azure Virtual Machines

First of all, we will spin up our virtual machines. What we want here is to have two Windows Server 2008 R2 virtual machines for our SignalR application and we will name them as Web1-08R2 and Web2-08R2. We will have the IIS installed on both of these servers and at the end, we will load balance the request on port 80.

Our third virtual machine will be another Windows Server 2008 R2 only for our Redis server. We will call this server Redis-08R2.

To spin up the VMs, go to new Windows Azure Management Portal and hit New icon at the bottom-right corner.


Creating a virtual machine running Windows Server 2008 R2 is explained here in details. We followed the same steps to create our first VM named Web1-08R2.

The second VM we will be creating has a slightly different approach than the first one. Under the hood, every virtual machine is a cloud service instance and we want to put our second VM (Web2-08R2) under the same cloud service that our first web VM is running under. To do that, we need to follow the same steps as explained inside the previously mentioned article but when we come to 3rd step in the creation wizard, we should chose Connect to existing Virtual Machine option this time and we should choose our first VM we have just created.


As the last step, we now need to create our redis VM which will be named Redis-08R2. We will follow the same steps as we did when we were creating our second web VM (Web2-08R2).

Setting Up Redis as a Windows Service

To use Redis on a Windows machine, we went to Redis on Windows prototype GitHub page and cloned the repository and followed the steps explained under How to build Redis using Visual Studio section.

After you build the project, you will have all the files you need under msvs\bin\release path as zip files. file will contain the redis server, redis command line interface and some other stuff. file will contain the msi file to install redis as a windows service. You can just copy those zip files to your Redis VM and extract under c:\redis\bin. Then follow the steps:

  • Currently, there is a bug in the RedisWatcher installer and if you don't have Microsoft Visual C++ 2010 Redistributable Package installed on your machine, the service won't start. So, I installed it first.

  • Copy this redis.conf file and put it under c:\redis\bin directory. Open it up and add a password by adding the following line of code:

    requirepass 1234567

    Take this note into considiration when you are setting up your redis password:

    Warning: since Redis is pretty fast an outside user can try up to 150k passwords per second against a good box. This means that you should use a very strong password otherwise it will be very easy to break.

  • Then, extract the somewhere and run the InstallWatcher.msito install the service.

  • Navigate to C:\Program Files (x86)\RedisWatcher directory. You will see a file named watcher.conf inside this directory. Open this file up and replace the entire file with the following text. Only difference here is that we are supplying the redis.conf file directory for the server to use:

    exepath c:\redis\bin
    exename redis-server.exe
     workingdir c:\redis\inst1
     runmode hidden
     saveout 1
     cmdparms c:\redis\bin\redis.conf
  • Create a folder named inst1 under c:\redis because we have specified this folder as working directory for our redis instance.

  • When you do a search against windows services in PowerShell, you will see RedisWatcherSvc service is installed.


  • Run the following PowerShell command to start the service for the first time.

    (Get-Service -Name RedisWatcherSvc).Start()

Now we have a Redis server running on our VM. To test if it is actually running, open up a windows command window under c:\redis\bin and run the following command (assuming you set your password 1234567):

redis-cli -h localhost -p 6379 -a 1234567

Now, you have a redis client running.


Ping the redis to see if you are really authenticated:


Now, we are nearly set. As a last step in our redis server, we need to open up TCP port 6379 for external communication. You can do this under Windows Firewall with Advanced Security window as explained here.


Communicating Through Internal Endpoints Between Windows Azure Virtual Machines Under Same Cloud Service

When you are inside one of your web VMs, you can simply look up the redis VM by hostname.


The hostname will resolve to DIP (Dynamic IP Address) which Windows Azure will use internally. We can configure public endpoints through Windows Azure Management Portal easily but in that case, we would be opening redis to the whole world. Also, if we communicate to our redis server through VIP (Virtual IP Address), we would always go through the load balancer which has its own additional cost.

So, we can easily connect to our redis server from any other connected VM by hostname.

The SignalR Application with Redis

Our SignalR application will not be that much different from a normal SignalR application thanks to SignalR.Redis project. All you need to do is to add the SignalR.Redis nuget package into your application and configure SignalR to use Redis as the message bus inside the Application_Start method in Global.asax.cs file:

protected void Application_Start(object sender, EventArgs e)
    // Hook up redis
    string server = ConfigurationManager.AppSettings["redis.server"];
    string port = ConfigurationManager.AppSettings["redis.port"];
    string password = ConfigurationManager.AppSettings["redis.password"];

    GlobalHost.DependencyResolver.UseRedis(server, Int32.Parse(port), password, "SignalR.Redis.Sample");

For our demo, the AppSettings should look like as below:

    <add key="redis.server" value="Redis-08R2" />
    <add key="redis.port" value="6379" />
    <add key="redis.password" value="1234567" />

I put the application under IIS on our both web servers (Web1-08R2 and Web2-08R2) and configured them to run under .NET Framework 4.0 integrated application pool.

For this demo, I am using the Redis.Sample chat application included inside the SignalR.Redis project.

Let's test them quickly before going public. I fired the both web applications inside the servers and here is the result:


Perfectly running! Let's open them up to the world.

Opening up the Port 80 and Load Balancing the Requets

Our requirement here is to make our application reachable over HTTP and at the same time, we want to load balance the request between our two web servers.

To do that, we need to go to Windows Azure Management portal and set up the TCP endpoints for port 80.

First, we navigate to dashboard of our Web1-08R2 VM and hit Endpoints from the dashboard menu:


From there, hit the End Endpoint icon at the bottom of the page:


A wizard is going to appear on the screen:


Click the right-arrow icon and go to next step which is the last one and we will enter the port details there:


After that, our endpoint will be created:


Follow the same steps of Web2-08R2 VM as well and open the Add Endpoint wizard. This time, we will be able to select Load-balance traffic on an existing port. Chose the previously created port and continue:


At the last step, enter the proper details and hit save:


We will see our new endpoint is being crated but this time Load Balanced column indicates Yes.


As we configured our web applications without a host name and they are exposed through port 80, we can directly run reach our application through the URL or Public Virtual IP Address (VIP) which is provided to us. When we run our application, we should see it running as below:


No matter which server it goes, the message will be broadcasted to every client because we will be using Redis as a message bus.


Learn how easy to scale out SignalR with a Redis backplane and simulate a local web farm scenario with IIS Express
@ 07-02-2013
by Tugberk Ugurlu

SignalR was built with scale out in mind from day one and they ship some scale out providers such as Redis, SQL Server and Windows Azure Service Bus. There is a really nice documentation series on this at official ASP.NET SignalR web site and you can find Redis, Windows Azure Service Bus and SQL Server samples there. In this quick post, I would like to show you how easy is to get SignalR up and running in a scale out scenario with a Redis backplane.

Sample Chat Application

First of all, I have a very simple and stupid real-time web application. The source code is also available on GitHub if you are interested in: RedisScaleOutSample. Guess what it is? Yes, you’re right. It’s a chat application :) I’m using SignalR 2.0.0-beta2 on this sample and here is how my hub looks like:

public class ChatHub : Hub
    public void Send(string message)

A very simple hub implementation. Now, let’s look at the entire HTML and JavaScript code that I have:

<!DOCTYPE html>
<html xmlns="">
    <title>Chat Sample</title>
        <input type="text" id="msg" /> 
        <button type="button" id="send">Send</button>
    <ul id="messages"></ul>

    <script src="/Scripts/jquery-1.6.4.min.js"></script>
    <script src="/Scripts/jquery.signalR-2.0.0-beta2.min.js"></script>
    <script src="/signalr/hubs"></script>
        (function () {

            var chatHub = $.connection.chatHub,
                msgContainer = $('#messages');

            chatHub.client.messageReceived = function (msg) {

            $.connection.hub.start().done(function () {

                $('#send').click(function () {
                    var msg = $('#msg').val();

When I run the application, I can see that it works like a charm:


This’s a single machine scenario and if we want to move this application to multiple VMs, a Web Farm or whatever your choice of scaling out your application, you will see that your application misbehaving. The reason is very simple to understand actually. Let’s try to understand why.

Understanding the Need of Backplane

Assume that you have two VMs for your super chat application: VM-1 and VM-2. The client-a comes to your application and your load balancer routes that request to VM-1. As your SignalR connection will be persisted as long as it can be, you will be connected to VM-1 for any messages you receive (assuming you are not on Long Pooling transport) and send (if you are on Web Sockets). Then, client-b comes to your application and the load balancer routes that request to VM-2 this time. What happens now? Any messages that client-a sends will not be received by client-b because they are on different nodes and SignalR has no idea about any other node except that it’s executing on.

To demonstrate this scenario easily in our development environment, I will fire up the same application in different ports through IIS Express with the following script:

function programfiles-dir {
    if (is64bit -eq $true) {
        (Get-Item "Env:ProgramFiles(x86)").Value
    } else {
        (Get-Item "Env:ProgramFiles").Value

function is64bit() {
    return ([IntPtr]::Size -eq 8)

$executingPath = (Split-Path -parent $MyInvocation.MyCommand.Definition)
$appPPath = (join-path $executingPath "RedisScaleOutSample")
$iisExpress = "$(programfiles-dir)\IIS Express\iisexpress.exe"
$args1 = "/path:$appPPath /port:9090 /clr:v4.0"
$args2 = "/path:$appPPath /port:9091 /clr:v4.0"

start-process $iisExpress $args1 -windowstyle Normal
start-process $iisExpress $args2 -windowstyle Normal

I’m running IIS Express here from the command line and it’s a very powerful feature if you ask me. When you execute the following script (which is run.ps1 in my sample application), you will have the chat application running on localhost:9090 and localhost:9091:


When we try to same scenario now by connecting both endpoints, you will see that it’s not working as it should be:


SignalR makes it really easy to solve this type of problems. In its core architecture, SignalR uses a pub/sub mechanism to broadcast the messages. Every message in SignalR goes through the message bus and by default, SignalR uses Microsoft.AspNet.SignalR.Messaging.MessageBus which implements IMessageBus as its in-memory message bus. However, this’s fully replaceable and it’s where you need to plug your own message bus implementation for your scale out scenarios. SignalR team provides bunch of backplanes for you to work with but if you can totally implement your own if none of the scale-out providers that SignalR team is providing is not enough for you. For instance, the community has a RabbitMQ message bus implementation for SignalR: SignalR.RabbitMq.

Hooking up Redis Backplane to Your SignalR Application

In order to test configure using Redis as the backplane for SignalR, we need to have a Redis server up and running somewhere. The Redis project does not directly support Windows but Microsoft Open Tech provides the Redis Windows port which targets both x86 and x64 bit architectures. The better news is that they distribute the binaries through NuGet:


Now I have Redis binaries, I can get the Redis server up. For our demonstration purposes, running the redis-server.exe without any arguments with the default configuration should be enough:


The Redis server is running on port 6379 now and we can configure SignalR to use Redis as its backplane. First thing to do is to install the SignalR Redis Messaging Backplane NuGet package. As I’m using the SignalR 2.0.0-beta2, I will install the version 2.0.0-beta2 of Microsoft.AspNet.SignalR.Redis package.


Last thing to do is to write a one line of code to replace the IMessageBus implementation:

public class Startup
    public void Configuration(IAppBuilder app)
            .UseRedis("localhost", 6379, string.Empty, "myApp");


The parameters we are passing into the UseRedis method are related to your Redis server. For our case here, we don’t have any password and that’s why we passed string.Empty. Now, let’s compile the application and run the same PowerShell script now to stand up two endpoints which simulates a web farm scenario in your development environment. When we navigate the both endpoints, we will see that messages are broadcasted to all nodes no matter which node they arrive:


That was insanely easy to implement, isn’t it.

A Few Things to Keep in Mind

The purpose of the SignalR’s backplane approach is to enable you to serve more clients in cases where one server is becoming your bottleneck. As you can imagine, having a backplane for your SignalR application can affect the message throughput as your messages need to go through the backplane first and distributed from there to all subscribers. For high-frequency real-time applications, such as real-time games, a backplane is not recommended. For those cases, cleverer load balancers are what you would want. Damian Edwards has talked about SignalR and different scale out cases on his Build 2013 talk and I strongly recommend you to check that out if you are interested in.

I just committed my first contribution to SignalR project: SignalR with Redis Running on a Windows Azure Virtual Machine. Enjoy :)
@ 07-03-2012
by Tugberk Ugurlu

I just committed my first contribution to SignalR project. No, it is not what you think. It doesn’t involve any code which is written by me. I am not that clever yet. Instead, I wrote a wiki article on SignalR’s Github Wiki on how to run a SignalR application with Redis running on a Windows Azure Virtual Machine: SignalR with Redis Running on a Windows Azure Virtual Machine.


@davidfowl had already done the most of the work with Signalr.Redis project and I just wrote the walkthrough article to leverage the new Windows Azure Virtual Machine feature.

Enjoy and give feedback :)

Hi πŸ™‹πŸ»β€β™‚οΈ I'm Tugberk Ugurlu.
Coder πŸ‘¨πŸ»β€πŸ’», Speaker πŸ—£, Author πŸ“š, Microsoft MVP πŸ•Έ, Blogger πŸ’», Software Engineering at Deliveroo πŸ•πŸœπŸŒ―, F1 fan πŸŽπŸš€, Loves travelling πŸ›«πŸ›¬
Lives in Cambridge, UK 🏑