We have two SignalR instances (different SignalR hubs hosted on separate servers and those servers are load balanced). We are planning to use SignalR Scaleout with SQL Server.
We have the following concerns
Use Common(single) database for both the signalr hubs (seperate signalr instance), is this fine?
Is it possible to generate signalr related tables under custom schema name in a database, based on the signalr instances?
That is the point of the backplane - a multitude of SignalR instances all using the same database. The only thing a backplane does is save messages from each instance to a central back store. Each instance will then poll the table for changes. Each instance will filter out it's own saved messages and detect the new messages from other instances, and will then send the new messages from other instances to the clients connected to it.
No. The SignalR schema name is hardcoded and is not configurable.
Related
I use SignalR in order to expose RabbitMQ messages to browsers. This works fine with one app instance obviously. The question is if it could work with multiple instances too without a backplane. I understand that SignalR client could be disconnected from the pod A and connected back to the pod B but what exactly is the issue here? I am fine to lose some messages during reconnection. Is it the only issue? Is reconnection to the pod B treated as a regular new connection so that the client is just subscribed again as it was subscribed normally without reconnection? Or the system doesn't have input parameters it had during initial subscription and therefore it cannot resubscribe without hints?
As long as all of your SignalR servers are getting the same data from RabbitMQ or getting only the data for the clients connected to them, you don't need a backplane.
You will need a backplane if you have one of the following:
Clients can communicate with one another.
One one SignalR server is connected to RabbitMQ but clients can connect to multiple SignalR servers.
SignalR servers are connected to different queues or getting different data from the same queue.
I have a similar setup with a database instead of RabbitMQ and need a backplane to either have only one of the SignalR servers access the database (and have data be sent to all clients) or to share the database load between servers (and have data be sent to all clients). This way, the server getting the data can have it sent to a client connected to a different server.
I am using SignalR for ASP.NET and the servers do not know who is subscribed to the other servers. All messages are sent over the backplane and each server determines if they apply to their connected clients. This works well with broadcasts for example or if the same user has multiple clients to make sure they all get the same data regardless of the server.
I have some questions regarding SignalR Core on the server side;
My server is written in ASP.NET Core, and it uses SignalR for sending notifications to users. The server uses Controllers with endpoints that clients interact with.
1) Can I host the entire thing in Azure App Service and add the SignalR service to it? Or would it be better to split the SignalR code out to its own server, which is called from the "main" server when needed?
2) The SignalR Service has an option for "Serverless", which according to documentation doesn't support clients calling any server RPCs when in said mode. Could I run this thing in Serverless mode as I'm only using the sockets for sending notifications to the clients. Or is it reserved for Azure functions?
3) Is there a way to get the number of connections for a user in a SignalR hub? I would like to send a push message to the user if he doesn't have any connections to the server. If not - what is the recommended way of handling this? I was thinking of adding a singleton service that keeps count, but am unsure if this would work at scale, especially with the SignalR service.
Thanks.
1) Better use the Azure SignalR.
2) Use it with the hub.
3) If you use Azure SignalR, you can just see it from the portal. In the code, whenever you use Azure SignalR or not, you can save the user Id in some var and count the connections. If you have multiple hubs and servers, you need to do more (if using redis-backplane for example).
If the answer is each hub has its own connection , how expensive are really these connections, lets say we have 3 hubs for 30K user connected is there really a performance gain if I reduce them to one hub ?
From docs :
Each connection object that you create encapsulates information about
a connection to a SignalR service that contains one or more Hub
classes. To communicate with a Hub class, you use a proxy object which
you create yourself (if you're not using the generated proxy) or which
is generated for you.
Also
All clients will use the same URL to establish a SignalR connection
with your service ("/signalr" or your custom URL if you specified
one), and that connection is used for all Hubs defined by the service.
I am in a stage of using SignalR in my project and i don't understand when to use Self hosted option and when we should not use. As a example if I am willing to host my web application in server farm,
There will be separate hosting servers
Separate SignalR hubs in each IIS server
If we want to broadcast message into each client, how this is working in SignalR
The idea with SignalR running in multiple instances is that clients connected on instance A cannot get messages from clients connected to instance B.
(SignalR scaleout documentation)
However, when you scale out, clients can get routed to different
servers. A client that is connected to one server will not receive
messages sent from another server.
The solution to this is using a backplane - everytime a server recieves a message, it forwards it to all other servers. You can do this using Azure Service Bus, Redis or SQL.
The way I see, you use the self host option when you either don't want the full IIS running (because you have some lightweight operations that don't require all IIS heaviness) or you don't want a web server at all (for example you want to add real-time functionality to an already existing let's say forms application, or in any other process).
Be sure to read the documentation for self-hosting SignalR and decide whether you actually need to self host SignalR.
If you are developing a web application under IIS, I don't see any reason why you would want to self-host SignalR.
Hope this helps. Best of luck!
We host different MVC5 web applications for the intranet(500 employees) on server farms. We want to lightly use signalR 2.2 with SQL Server service broker backplane, mainly for server broadcast. We want to use the same backplane DB for different applications, all applications having acces to the backplane DB server.
Question : 1-Is it to avoid in terms of performance, I didn't see any good practice guidance and it seems to work technically. 2-If a message is broadcast to application1 clients, will it be sent to clients of Application2 also?3-What would be the advantages of using separate backplane DB for each application?
Up to version 2.x, I don't think that is a good idea because it would probably be inefficient. It might work, but the current mechanism would broadcast all messages to all apps using the same connection string (= same server + same database). There is no way to segregate applications on the same database. It looks like there is a plan for it in future versions, but as of today it's probably not recommended.