Guide des performances pour le Service Azure Web PubSub
L’un des principaux avantages à utiliser le service Azure Web PubSub est la facilité de mise à l’échelle. Dans un scénario à grande échelle, les performances sont un facteur important.
Dans ce guide, nous vous présentons les facteurs qui affectent le niveau de performance du service Web PubSub. Nous décrirons le niveau de performance typique dans différents scénarios de cas d’utilisation.
Évaluation rapide à l’aide de métriques
Avant de passer en revue les facteurs qui impactent les performances, commençons par présenter un moyen facile de superviser la sollicitation de votre service. Il existe une métrique appelée Charge du serveur sur le portail.
Elle indique la sollicitation informatique de votre service Azure Web PubSub. Vous pouvez tester sur votre propre scénario et vérifier cette métrique pour décider s’il faut effectuer un scale-up. La latence au sein du service Azure Web PubSub reste faible si la charge du serveur est inférieure à 70 %.
Remarque
Si vous utilisez l’unité 50 ou supérieure et que votre scénario envoie principalement à des petits groupes (taille de groupe < 20), vous devez vérifier envoyer à un petit groupe à des fins de référence. Dans ces scénarios, il existe un coût de routage important qui n’est pas inclus dans la charge du serveur.
Voici les concepts détaillés de l’évaluation des performances.
Définitions des termes
Entrant : message entrant à destination du Service Azure Web PubSub.
Sortant : message sortant en provenance du Service Azure Web PubSub.
Bande passante : taille totale de tous les messages en 1 seconde.
Vue d’ensemble
Ce guide répond aux questions suivantes :
Quelles est le niveau de performance typique du service Azure Web PubSub pour chaque taille d’unité ?
Le Service Azure Web PubSub répond-il à mes exigences de débit de message (par exemple, l’envoi de 100 000 messages par seconde) ?
Pour mon scénario spécifique, comment puis-je sélectionner la taille d’unité appropriée ?
Pour répondre à ces questions, ce guide fournit tout d’abord une explication générale des facteurs qui affectent les performances. Il illustre ensuite le nombre maximal de messages entrants et sortants pour des cas d’usage classique : envoi aux groupes via le sous-protocole Web PubSub, en amont et via l’API REST.
Ce guide ne peut pas couvrir tous les scénarios (ni différents cas d’usage, tailles de message, modèles d’envoi de messages, etc.). Mais il fournit des informations de base pour comprendre la limitation des performances.
Insight des performances
Cette section décrit les méthodes d’évaluation des performances, puis liste tous les facteurs qui affectent celles-ci. Enfin, elle fournit des méthodes pour vous aider à évaluer les exigences de performance.
Méthodologie
Le débit et la latence sont deux aspects typiques de la vérification des performances. Le débit maximal (bande passante entrante et sortante) est défini comme le débit maximal atteint lorsque 99 % des messages ont une latence inférieure à une seconde. Ce n’est pas une limite stricte.
Facteurs de performances
En théorie, la capacité du Service Azure Web PubSub est limitée par les ressources de calcul : processeur, mémoire et réseau. Par exemple, plus il y a de connexions au Service Azure Web PubSub, plus le service utilise de mémoire. Pour le trafic de messages plus volumineux (par exemple, chaque message est supérieur à 2 048 octets), le Service Azure Web PubSub doit dépenser plus de cycles de processeur pour traiter le trafic.
Le coût de routage des messages limite également les performances. Le Service Azure Web PubSub joue le rôle de répartiteur de message, lequel achemine le message entre un ensemble de clients. Un scénario ou API différent nécessite une stratégie de routage différente.
Pour echo, le client envoie un message en amont, et le service en amont renvoie ce message au client. Ce modèle présente le coût de routage le plus bas. Par contre, pour la diffusion, l’envoi au groupe et l’envoi à la connexion, le Service Azure Web PubSub doit rechercher les connexions cibles par le biais de la structure de données distribuée interne. Ce traitement supplémentaire utilise davantage de processeur, de mémoire et de bande passante réseau. Ainsi, les performances sont plus lentes.
En résumé, les facteurs suivants affectent les capacités entrante et sortante :
Taille d’unité (processeur/mémoire)
Nombre de connexions
Taille des messages
Débit d’envoi des messages
Scénario d’utilisation (coût de routage)
Rechercher une taille d’unité appropriée
Comment pouvez-vous évaluer la capacité entrante/sortante ou savoir quelle taille d’unité est appropriée pour un cas d’usage spécifique ?
Chaque taille d’unité a ses propres bandes passantes entrante et sortante maximales. Une fois que le trafic entrant ou sortant dépasse le seuil, la fluidité de l’expérience utilisateur n’est pas garantie.
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
- inboundConnections : nombre de connexions envoyant le message.
- outboundConnections : nombre de connexions recevant le message.
- messageSize : taille d’un message unique (valeur moyenne). Un petit message inférieur à 1 024 octets a un impact sur les performances similaire à un message de 1 024 octets.
- sendInterval: intervalle d’envoi des messages. Par exemple, 1 seconde signifie l’envoi d’un message toutes les secondes. Un intervalle plus petit signifie l’envoi de davantage de messages au cours d’une période. Par exemple, 0,5 seconde signifie l’envoi de deux messages par seconde.
- Connexions : seuil maximal validé pour le service Azure Web PubSub pour chaque taille d’unité. Les connexions qui dépassent le seuil sont limitées.
Supposons que le service en amont est suffisamment puissant et qu’il n’est pas le goulot d’étranglement des performances. Ensuite, vérifiez la bande passante entrante et sortante maximale pour chaque taille d’unité.
Étude de cas
Les sections suivantes abordent trois cas d’utilisation classiques : l’envoi aux groupes via le sous-protocole Azure Web PubSub, le déclenchement de CloudEvent, l’appel de l’api rest. Pour chaque scénario, la section liste les capacités entrantes et sortantes actuelles pour le Service Azure Web PubSub. Elle explique également les principaux facteurs qui affectent les performances.
Dans tous les cas d’usage, la taille de message par défaut est de 2 048 octets, tandis que l’intervalle d’envoi des messages est de 1 seconde.
Envoyer à des groupes via le sous-protocole Azure Web PubSub
Le service prend en charge un sous-protocole spécifique appelé json.webpubsub.azure.v1, qui permet aux clients de publier/s’abonner directement à la place d’un aller-retour au serveur en amont. Ce scénario est efficace, car aucun serveur n’est impliqué et tout le trafic transite par la connexion WebSocket du service client.
Le nombre de membres par groupe et de groupes sont deux facteurs qui affectent les performances. Pour simplifier l’analyse, nous définissons deux types de groupes :
- Big group : le nombre de groupes est toujours de 10. Le nombre de membres par groupe est égal à (nombre de connexions maximal) / 10. Par exemple, pour l’Unité 1, si le nombre de connexions s’élève à 1000, alors chaque groupe a 1000 / 10 = 100 membres.
- Small group : chaque groupe comporte 10 connexions. Le nombre de groupes est égal à (nombre de connexions maximal) / 10. Par exemple, pour l’Unité 1, si le nombre de connexions s’élève à 1000, alors nous avons 1000 / 10 = 100 groupes.
L’envoi au groupe implique un coût de routage pour le Service Azure Web PubSub, car il doit rechercher les connexions cibles par le biais d’une structure de données distribuée. Plus le nombre de connexions d’envoi augmente, plus le coût s’accroît.
Grand groupe
Pour le cas d’usage envoi à un grand groupe, la bande passante sortante devient le goulot d’étranglement avant d’atteindre la limite du coût de routage. Le tableau suivant liste la bande passante sortante maximum.
| Envoi à un grand groupe | Unité 1 | Unité 2 | Unité 10 | Unité 50 | Unité 100 | Unité 200 | Unité 500 | Unité 1000 |
|---|---|---|---|---|---|---|---|---|
| Connexions | 1 000 | 2 000 | 10 000 | 50 000 | 100 000 | 200 000 | 500 000 | 1 000 000 |
| Nombre de membres par groupe | 100 | 200 | 1 000 | 5 000 | 10 000 | 5 000 | 10 000 | 20 000 |
| Nombre de groupes | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Messages entrants par seconde | 30 | 30 | 30 | 30 | 30 | 30 | 30 | 30 |
| Bande passante entrante | 60 Kbits/s | 60 Kbits/s | 60 Kbits/s | 60 Kbits/s | 60 Kbits/s | 60 Kbits/s | 60 Kbits/s | 60 Kbits/s |
| Messages sortants par seconde | 3 000 | 6 000 / 750 | 30,000 | 150 000 | 300 000 | 600 000 | 1 500 000 | 3 000 000 |
| Bande passante sortante | 6 Mbits/s | 12 Mbits/s | 60 Mbits/s | 300 Mbits/s | 600 Mbits/s | 1200 Mbits/s | 3000 Mbits/s | 6000 Mbits/s |
Petit groupe
Le coût de routage est important pour l’envoi de message à de nombreux petits groupes. L’implémentation du Service Azure Web PubSub atteint la limite du coût de routage à l’unité 50. L’ajout de ressources en processeur et en mémoire n’étant pas efficace, l’Unité 100 ne peut pas en soi apporter d’amélioration. Si vous avez besoin d’une bande passante entrante plus importante, vous devez effectuer un scale-up pour utiliser Premium_P2(unité > 100).
| Envoi à un petit groupe | Unité 1 | Unité 2 | Unité 10 | Unité 50 | Unité 100 | Unité 200 | Unité 500 | Unité 1000 |
|---|---|---|---|---|---|---|---|---|
| Connexions | 1 000 | 2 000 | 10 000 | 50 000 | 100 000 | 200 000 | 500 000 | 1 000 000 |
| Nombre de membres par groupe | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Nombre de groupes | 100 | 200 | 1 000 | 5 000 | 10 000 | 20 000 | 50 000 | 100 000 |
| Messages entrants par seconde | 200 | 400 | 2 000 | 10 000 | 10 000 | 20 000 | 50 000 | 100 000 |
| Bande passante entrante | 400 Kbits/s | 800 Kbits/s | 4 Mbits/s | 20 Mbits/s | 20 Mbits/s | 40 Mbits/s | 100 Mbits/s | 200 Mbits/s |
| Messages sortants par seconde | 2 000 | 4 000 | 20 000 | 100 000 | 100 000 | 200 000 | 500 000 | 1 000 000 |
| Bande passante sortante | 4 Mbits/s | 8 Mbits/s | 40 Mbits/s | 200 Mbits/s | 200 Mbits/s | 400 Mbits/s | 1000 Mbits/s | 2000 Mbits/s |
Remarque
Le nombre de groupes et le nombre de membres de groupe listés dans la table ne sont pas des limites strictes. Ces valeurs de paramètre sont sélectionnées pour établir un scénario de point de référence stable.
Déclenchement de l’événement Cloud
Le service fournit des événements client au webhook en amont à l’aide du protocole http CloudEvents.
Pour chaque événement, il formule une requête HTTP POST au service en amont enregistré et attend une réponse HTTP.
Remarque
Le Web PubSub prend également en charge le protocole HTTP 2.0 pour la remise des événements en amont. Le résultat ci-dessous est testé à l’aide de HTTP 1.1. Si votre serveur d’applications prend en charge HTTP 2.0, les performances seront meilleures.
Écho
Dans ce cas, le serveur d’applications réécrit le message d’origine dans la réponse http. Le comportement du cas d’usage écho détermine que la bande passante entrante maximale est égale à la bande passante sortante maximale. Pour plus de détails, consultez le tableau suivant.
| Écho | Unité 1 | Unité 2 | Unité 10 | Unité 50 | Unité 100 | Unité 200 | Unité 500 | Unité 1000 |
|---|---|---|---|---|---|---|---|---|
| Connexions | 1 000 | 2 000 | 10 000 | 50 000 | 100 000 | 200 000 | 500 000 | 1 000 000 |
| Messages entrants/sortants par seconde | 500 | 1 000 | 5 000 | 25 000 | 50 000 | 100 000 | 250 000 | 500 000 |
| Bande passante entrante/sortante | 1 Mbits/s | 2 Mbits/s | 10 Mbits/s | 50 Mbits/s | 100 Mbits/s | 200 Mbits/s | 500 Mbits/s | 1000 Mbits/s |
API REST
Le Service Azure Web PubSub fournit des API puissantes pour gérer les clients et remettre des messages en temps réel.
Envoi à l’utilisateur par le biais de l’API REST
Le point de référence attribue des noms d’utilisateur à tous les clients avant qu’ils ne commencent à se connecter au Service Azure Web PubSub.
| Envoi à l’utilisateur par le biais de l’API REST | Unité 1 | Unité 2 | Unité 10 | Unité 50 | Unité 100 | Unité 200 | Unité 500 | Unité 1000 |
|---|---|---|---|---|---|---|---|---|
| Connexions | 1 000 | 2 000 | 10 000 | 50 000 | 100 000 | 200 000 | 500 000 | 1 000 000 |
| Messages entrants/sortants par seconde | 180 | 360 | 1 800 | 9 000 | 18 000 | 36 000 | 90 000 | 180 000 |
| Bande passante entrante/sortante | 360 Kbits/s | 720 Kbits/s | 3,6 Mbits/s | 18 Mbits/s | 36 Mbits/s | 72 Mbits/s | 180 Mbits/s | 360 Mbits/s |
Diffusion par le biais de l’API REST
La bande passante est la même que pour Envoyer à un grand groupe.
| Diffusion par le biais de l’API REST | Unité 1 | Unité 2 | Unité 10 | Unité 50 | Unité 100 | Unité 200 | Unité 500 | Unité 1000 |
|---|---|---|---|---|---|---|---|---|
| Connexions | 1 000 | 2 000 | 10 000 | 50 000 | 100 000 | 200 000 | 500 000 | 1 000 000 |
| Messages entrants par seconde | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 |
| Messages sortants par seconde | 3 000 | 6 000 / 750 | 30,000 | 150 000 | 300 000 | 600 000 | 1 500 000 | 3 000 000 |
| Bande passante entrante | 6 Kbits/s | 6 Kbits/s | 6 Kbits/s | 6 Kbits/s | 6 Kbits/s | 6 Kbits/s | 6 Kbits/s | 6 Kbits/s |
| Bande passante sortante | 6 Mbits/s | 12 Mbits/s | 60 Mbits/s | 300 Mbits/s | 600 Mbits/s | 1200 Mbits/s | 3000 Mbit/s | 6000 Mbit/s |
Étapes suivantes
Utilisez ces ressources pour commencer à créer votre propre application :