Multiple SignalR hub types over one backplane — pros/cons/scalability?

Question

Recently we've tried to change the SignalR on a couple web apps to work in a web farm situation by using a SQL backplane.

The number of different ways we could tweak it are multiplying in my head as I explore how it's working (toward the goal of most scalability, least points of failure).

Currently SignalR is used by each app to support a poll-driven broadcast of changes noted in the database.

Essential assumptions/observations about using one backplane for all SignalR instances on all apps:

1. All hubs and hub instances (of all types) that have one common backplane live on just one messagebus.

2. All hub instances essentially "merge" their client pool. The hub instance cannot actually know how many clients they have.

3. Message traffic from some AppB_Hub can be seen in trace output from AppA. I assume if AppA had a hub with the same name they'd be in conflict -- or maybe not as long as they realized they'd be sharing clients.

Questions/concerns/unknowns:

1. Do different hubs (different hub type, possibly different assembly) play nicely? ie would messages & calls on one ever interfere with the other? In what situations?
2. Is it all based on naming? ie if AppAHub and AppBHub want to play nicely do they need to make sure their method & calback names are different? Or are they already different as long as the hub names are different?
3. Assuming it's "safe enough", does it "scale out" well to have each app sifting through each other app's messages. Is it worth it to have a separate backplane at some scale. Is it worth it at a small scale? eg: 2 types of hub, 2 instances of each.
4. Alternately there is the possibility that AppAHub and AppBHub could really be just two interfaces into the same hub, so AppA can potentially stay informed about AppB & vice versa. I wonder if there's any point in them being separate hubs if we know they'll all be fed everything. OR does that activate some unavoidable additional cost for AppA now that it more explicitly "cares" about AppB messages?

Answer 1

Hub are stand alone , so different hubs play nice , how ever if you place them in different assembly and want to access each other , see here

names and callback are based on which hub your client connects to , they should be unique for debugging purposes, if you client connects to 1 or more different hub if each client connects to only one hub

for performance counter, see here , Microsoft uses signlR back plane in their azure web services , so it does scale however there is not published whitepapers on the benchmark figures

If you want to use the interfaces approach IAppAHub and IAppBHub your java script client can call IAppAHub and IAppBHub methods , if you want to limit you can to it by role for that you should look into SignalR securty