0

I use Redis as a backplane, but I'm also using SQL to map users to connections. This is taking a toll on my I/O - every time I send a message through my hub, I do this: 

private readonly ConnectionService _connectionService;

public AppHub() {
   _connectionService = new ConnectionService();
}

public void SendClientNotification(string notification, string key) {
   List<string> navbarClients = _connectionService.GetConnections(key); // yuck
   foreach (string connectionId in navbarClients) {
       Clients.Client(connectionId).clientNotification(notification);
    }
}

Where GetConnections is this: 

public List<string> GetConnections(string key) {
    using (DbContext db = new DbContext()) {
       return db.SignalConnections
            .Where(s => s.Key == key)
            .Select(s => s.ConnectionGuid)
            .ToList();
    }
}

I also do a whole bunch of I/O to periodically delete inactive connections.

Can SignalR somehow infer the username (say from User.Identity.Name) and automatically handle the mapping and connection expiration so I can just wipe out this SQL dependency from my SignalR implementation?

Maria Ines Parnisari
  • 16,584
  • 9
  • 85
  • 130
SB2055
  • 12,272
  • 32
  • 97
  • 202
  • If you're already using redis for the backplane, why not also use it to store the mappings? – Brendan Green Jun 04 '17 at 03:25
  • @BrendanGreen is there an example of how to do that? Is that kind of a no-brainer as far as performance? – SB2055 Jun 04 '17 at 12:26
  • SignalR itself does handle the connections for you. There are events you can subscribe to in order to save clients connected / disconnected of you want bit there's no reason to store or cycle sny data yourself for connections. This should be used only to reset if your server was reset and even then it's a design choice that may be overkill. In the event your server goes down and comes back it'll be ok for the user to reconnect on their end. It should rarely if ever happen. Let SignalR do all the work. – Michael Puckett II Jun 05 '17 at 05:55

0 Answers0