La diffusion dans des groupes vides, comme vous le décrivez, a un peu de surcharge, mais elle est probablement négligeable selon votre cas d'utilisation. Imaginons que vous ayez 100 000 messages à traiter dans une file d'attente. Le traitement de l'un de ces messages peut vous obliger à envoyer un message SignalR aux clients qui surveillent ces données, mais la grande majorité des messages n'aura aucun observateur.
Vous pouvez utiliser le message/ID d'entité comme le nom du groupe et exécuter du code comme celui-ci pour chacun des 100.000 messages:
var hub = GlobalHost.ConnectionManager.GetHubContext(hubName);
var group = hub.Clients.Group(groupName) as GroupProxy;
if (group != null)
{
group.Invoke(actionName, messageData);
}
Sinon, si vous étiez en quelque sorte en mesure de gérer un HashSet de groupes qui ont réellement des clients (ou sont susceptibles d'avoir des clients) alors vous pouvez modifier votre code comme ceci:
var activeGroups = new HashSet<string>();
...
if (activeGroups.Contains(groupName))
{
var hub = GlobalHost.ConnectionManager.GetHubContext(hubName);
var group = hub.Clients.Group(groupName) as GroupProxy;
if (group != null)
{
group.Invoke(actionName, messageData);
}
}
Ce second exemple semble exagéré et introduit la complexité de la gestion activeGroups (qui peut Probab peut être fait dans une sous-classe personnalisée de Hub). De plus, je m'attendais à ce que SignalR fasse déjà quelque chose comme ça. Cependant, quand je compare cela avec 100 000 messages et zéro client (ie: chaque groupe est vide), je reçois 2,5 secondes sur le premier exemple et 0,006 secondes sur le second exemple. Quoi que fasse SignalR en interne pour gérer les groupes vides, il est certainement moins efficace qu'une recherche HashSet.
Exécution du premier test (le lent) dans l'exécution Visual Studio profileur confirme que la plupart des travaux est dans les fonctions internes SignalR qui sont lents comparés de façon inattendue à un HashSet:
