Partage via

Messages et connexions dans Azure SignalR Service

  • Article

Le modèle de facturation d’Azure SignalR Service est basé sur le nombre de connexions et le nombre de messages sortants à partir du service. Cet article explique de quelle manière les messages et les connexions sont définis et comptabilisés en vue de la facturation.

Formats des messages

Azure SignalR Service prend en charge les mêmes formats qu’ASP.NET Core SignalR : JSON et MessagePack.

Taille des messages

Les limites suivantes s’appliquent aux messages Azure SignalR Service :

  • Messages client :
    • Pour les événements de longue durée d’interrogation ou côté serveur, le client ne peut pas envoyer de messages de plus de 1 Mo.
    • Il n’existe aucune limite de taille pour WebSocket pour le service.
    • Le serveur d’applications peut définir une limite pour la taille des messages client. La valeur par défaut est 32 Ko. Pour plus d'informations, consultez Considérations sur la sécurité dans ASP.NET Core SignalR
    • Pour le serverless, la taille du message est limitée par l’implémentation en amont, mais une taille de moins de 1 Mo est recommandée.
  • Messages de serveur :

Pour les clients WebSocket, les messages volumineux sont divisés en messages plus petits de 2 Ko maximum chacun et sont transmis séparément. Des SDK gèrent la division et l’assemblage des messages. Aucune implication des développeurs n’est nécessaire.

Les messages volumineux diminuent les performances de messagerie. Utilisez les messages les plus petits possibles et faites des tests afin de déterminer la taille de message optimale pour chaque scénario d’usage.

Mode de calcul des messages pour la facturation

Les messages envoyés au service sont des messages entrants et les messages envoyés en dehors du service sont des messages sortants. Seuls les messages envoyés à partir d’Azure SignalR Service sont comptabilisés pour la facturation. Les messages Ping transmis entre les clients et les serveurs ne sont pas pris en compte.

Les messages de plus de 2 Ko sont comptabilisés comme plusieurs messages de 2 Ko chacun. Le graphique du nombre de messages dans le portail Azure est mis à jour tous les 100 messages par hub.

Par exemple, imaginez que vous avez un serveur d’applications et trois clients :

  • Le serveur d’applications diffuse un message de 1 Ko à tous les clients connectés : le message du serveur d’applications au service est considéré comme un message entrant gratuit. Les trois messages envoyés à partir du service à chaque client sont des messages sortants et facturés.

  • Quand le client A envoie un message entrant de 1 Ko au client B sans passer par un serveur d’applications, il s’agit d’un message entrant gratuit. Le message acheminé à partir du service au client B est facturé comme message sortant.

  • Quand un client envoie un message de 4 Ko pour une diffusion de serveur à tous les clients et qu’il existe trois clients et un serveur d’applications, le nombre de messages facturés est de huit :

    • Un message du service vers le serveur d’applications.
    • Trois messages du service aux clients. Chaque message est comptabilisé comme deux messages de 2 Ko chacun.

Mode de calcul des connexions

Azure SignalR Service crée un serveur d’applications et des connexions au client. Par défaut, chaque serveur d’applications démarre avec cinq connexions initiales par hub et chaque client dispose d’une connexion client.

Par exemple, imaginez que vous utilisez deux serveurs d’applications et que vous définissez cinq hubs dans le code. Le nombre de connexions au serveur est de 50 : (2 serveurs d’applications * 5 hubs * 5 connexions par hub).

Le nombre de connexions indiqué dans le Portail Azure comprend les connexions au serveur, au client, de diagnostic et de trace dynamique. Les types de connexion sont définis dans la liste suivante :

  • Connexion au serveur : Connecte Azure SignalR Service et le serveur d’applications.
  • Connexion au client : Connecte Azure SignalR Service et l’application cliente.
  • Connexion de diagnostic : type spécial de connexion au client qui peut produire un journal plus détaillé, ce qui est susceptible d’avoir un impact sur les performances. Ce type de client est conçu pour la résolution des problèmes.
  • Connexion de trace dynamique : Se connecte au point de terminaison de la trace dynamique et reçoit les traces dynamiques d’Azure SignalR Service.

Une connexion de trace dynamique n’est pas comptabilisée comme connexion au client ni comme connexion au serveur.

ASP.NET SignalR calcule le nombre de connexions serveur de manière différente. Il inclut un hub par défaut en plus des hubs que vous définissez. Par défaut, chaque serveur d’applications a besoin de cinq connexions serveur initiales supplémentaires. Le nombre de connexions initiales pour le hub par défaut reste cohérent avec les autres hubs.

Le service et le serveur d’applications continuent à synchroniser l’état de la connexion et à ajuster les connexions au serveur pour obtenir de meilleures performances et une stabilité supérieure du service. Il est donc possible que vous voyiez des modifications au nombre de connexions au serveur dans votre service en cours d’exécution.