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 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 que ASP.NET Core SignalR : JSON et MessagePack.

Taille du message

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

  • Messages clients :
    • Pour les événements longs 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 serverless, la taille du message est limitée par amont implémentation, mais moins de 1 Mo est recommandée.
  • Messages serveur :
    • Il n’existe aucune limite à la taille des messages du serveur, mais moins de 16 Mo est recommandée.
    • 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
    • Serverless :
      • API rest : 1 Mo pour le corps du message, 16 Ko pour les en-têtes.
      • Il n’existe aucune limite pour WebSocket, le SDK de gestion persis mode tente mais moins de 16 Mo est recommandé.

Pour les clients WebSocket, les messages volumineux sont divisés en messages plus petits qui ne sont pas plus de 2 Ko chacun et 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 hors du service sont des messages sortants. Seuls les messages sortants 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 :

  • Lorsque 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 du service à chacun des clients sont des messages sortants et sont facturés.

  • Lorsque le client A envoie un message entrant 1 Ko au client B, sans passer par le serveur d’applications, le message est un message entrant gratuit. Le message acheminé du service vers le client B est facturé en tant que message sortant.

  • Si vous avez trois clients et un serveur d’applications, lorsqu’un client envoie un message de 4 Ko pour le serveur diffusé à tous les clients, le nombre de messages facturés est de huit :

    • Un message du service au 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 clientes. 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 de serveur est de 50 : (2 serveurs d’applications * 5 hubs * 5 connexions par hub).

Le nombre de connexions indiqué dans le Portail Azure inclut les connexions de serveur, de 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 client qui peut produire un journal plus détaillé, ce qui peut affecter 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 en tant que connexion cliente ou en tant que connexion de 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 conservent l’état de la connexion et effectuent des ajustements pour obtenir de meilleures performances et une meilleure stabilité du service. Vous pouvez donc voir les modifications apportées au nombre de connexions de serveur dans votre service en cours d’exécution.