Concepts clés pour les nouveaux utilisateurs azure Load Testing

Découvrez les principaux concepts et composants d’Azure Load Testing. Ces informations peuvent vous aider à configurer plus efficacement un test de charge pour identifier les problèmes de performances dans votre application.

Concepts généraux du test de charge

Découvrez les concepts clés liés à l’exécution de tests de charge.

Utilisateurs virtuels

Un utilisateur virtuel exécute un cas de test particulier sur votre application serveur et s’exécute indépendamment d’autres utilisateurs virtuels. Vous pouvez utiliser plusieurs utilisateurs virtuels pour simuler des connexions simultanées à votre application serveur.

Apache JMeter fait également référence aux utilisateurs virtuels en tant que threads. Dans le script de test JMeter, un élément de groupe de threads vous permet de spécifier le pool d’utilisateurs virtuels. Découvrez les groupes de threads dans la documentation Apache JMeter.

Locust fait référence aux utilisateurs virtuels en tant qu’utilisateurs. Vous pouvez spécifier les utilisateurs nécessaires à votre test dans l’interface web, en tant qu’argument de ligne de commande, via une variable d’environnement ou via un fichier de configuration. Pour plus d’informations, consultez les options de configuration de la documentation locust.

Le nombre total d’utilisateurs virtuels pour votre test de charge dépend du nombre d’utilisateurs virtuels dans le script de test et du nombre d’instances de moteur de test.

Pour les tests de charge basés sur JMeter, la formule est : Nombre total d’utilisateurs virtuels = (utilisateurs virtuels dans le fichier JMX) * (nombre d’instances de moteur de test).

Vous pouvez atteindre le nombre cible d’utilisateurs virtuels en configurant le nombre d’instances de moteur de test, le nombre d’utilisateurs virtuels dans le script de test ou une combinaison des deux.

Pour les tests de charge basés sur locust, le nombre total d’utilisateurs virtuels est le nombre d’utilisateurs spécifiés par l’une des options de configuration. Vous pouvez ensuite configurer le nombre d’instances de moteur de test requises pour générer le nombre total d’utilisateurs.

Temps d’accélération

Le temps d’accélération est le temps nécessaire pour atteindre le nombre total d’utilisateurs virtuels pour le test de charge. Si le nombre d’utilisateurs virtuels est de 20 et que le temps d’accélération est de 120 secondes, il faut 120 secondes pour accéder à 20 utilisateurs virtuels. Chaque utilisateur virtuel démarre 6 (120/20) secondes après le démarrage de l’utilisateur précédent.

Pour Locust, vous pouvez configurer une montée en puissance à l’aide du taux de génération. Le taux de génération est le nombre d’utilisateurs ajoutés par seconde. Par exemple, si le nombre d’utilisateurs est de 20 et que le taux de génération est de 2, 2 utilisateurs sont ajoutés toutes les secondes, et il faut 10 secondes pour accéder à tous les 20 utilisateurs.

Temps de réponse

Le temps de réponse d’une demande individuelle ou de temps écoulé dans JMeter est le temps total de juste avant d’envoyer la demande juste après la réception de la dernière réponse. Le temps de réponse n’inclut pas le temps de rendu de la réponse. Tout code client, tel que JavaScript, n’est pas traité pendant le test de charge.

Latence

La latence d’une requête individuelle est la durée totale entre juste avant l’envoi de la demande juste après la réception de la première réponse. La latence inclut tout le traitement nécessaire pour assembler la demande et assembler la première partie de la réponse.

Demandes par seconde (RPS)

Les requêtes par seconde (RPS) ou le débit sont le nombre total de requêtes adressées à l’application serveur que votre test de charge génère par seconde.

La formule est : RPS = (nombre de requêtes) / (temps total en secondes).

L’heure est calculée entre le début du premier échantillon et la fin du dernier échantillon. Cette durée inclut tous les intervalles entre les échantillons, par exemple si le script de test contient des minuteurs.

Une autre façon de calculer le RPS est basée sur la latence moyenne de l’application et le nombre d’utilisateurs virtuels. Pour simuler un nombre spécifique de RPS avec un test de charge, étant donné la latence de l’application, vous pouvez ensuite calculer le nombre requis d’utilisateurs virtuels.

La formule est : Utilisateurs virtuels = (RPS) * (latence en secondes).

Par exemple, étant donné une latence d’application de 20 millisecondes (0,02 secondes), pour simuler 100 000 RPS, vous devez configurer le test de charge avec 2 000 utilisateurs virtuels (100 000 * 0,02).

Composants Azure Test de Charge

Découvrez les principaux concepts et composants d’Azure Load Testing. Le diagramme suivant donne une vue d’ensemble de la façon dont les différents concepts se rapportent les uns aux autres.

Ressource de test de charge

La ressource de test de charge Azure est la ressource de niveau supérieur pour vos activités de test de charge. Cette ressource fournit un emplacement centralisé pour afficher et gérer les tests de charge, les résultats des tests et les artefacts associés.

Lorsque vous créez une ressource de test de charge, vous spécifiez son emplacement, qui détermine l’emplacement des moteurs de test. Azure Load Testing chiffre automatiquement tous les artefacts de votre ressource. Vous pouvez choisir entre les clés gérées par Microsoft ou utiliser vos propres clés gérées par le client pour le chiffrement.

Pour exécuter un test de charge pour votre application, vous ajoutez un test à votre ressource de test de charge. Une ressource peut contenir zéro ou plusieurs tests.

Vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure pour accorder l’accès à votre ressource de test de charge et aux artefacts associés.

Azure Load Testing vous permet d’utiliser des identités managées à différentes fins, telles que l’accès à Azure Key Vault pour stocker les paramètres de secret de test de charge ou les certificats, l’accès aux métriques Azure Monitor pour configurer des critères d’échec ou simuler des flux d’authentification basés sur des identités managées.

Essai

Un test décrit la configuration du test de charge pour votre application. Vous ajoutez un test à une ressource de test de charge Azure existante.

Un test contient un plan de test, qui décrit les étapes à suivre pour appeler le point de terminaison de l’application. Vous pouvez définir le plan de test de l’une des trois manières suivantes :

• Chargez un script de test JMeter.
• Chargez un script de test Locust.
• Spécifiez la liste des points de terminaison d’URL à tester.

Azure Load Testing prend en charge tous les protocoles de communication pris en charge par JMeter et Locust, et non seulement les points de terminaison HTTP. Par exemple, vous pouvez lire ou écrire dans une base de données ou une file d’attente de messages dans le script de test.

Actuellement, Azure Load Testing ne prend pas en charge d’autres frameworks de test que Apache JMeter et Locust.

Le test spécifie également les paramètres de configuration pour l’exécution du test de charge :

• Paramètres de test de charge, tels que les variables d’environnement, les secrets et les certificats.
• Chargez la configuration pour effectuer un scale-out de votre test de charge sur plusieurs instances de moteur de test .
• Critères d’échec pour déterminer quand le test doit réussir ou échouer.
• Paramètres de supervision pour configurer la liste des composants d’application Azure et des métriques de ressources à surveiller pendant l’exécution du test.

En outre, vous pouvez charger des fichiers de données d’entrée CSV et tester des fichiers de configuration dans le test de charge.

Lorsque vous démarrez un test, Azure Load Testing déploie le script de test, les fichiers associés et la configuration sur les instances du moteur de test. Les instances du moteur de test lancent ensuite le script de test pour simuler la charge de l’application.

Chaque fois que vous démarrez un test, Azure Load Testing crée une instance de test et l’attache au test.

Exécution de test

Une exécution de test représente une exécution d’un test de charge. Lorsque vous exécutez un test, l’exécution du test contient une copie des paramètres de configuration à partir du test associé.

Une fois l’exécution du test terminée, vous pouvez afficher et analyser les résultats des tests de charge dans le tableau de bord Test de charge Azure dans le portail Azure.

Vous pouvez également télécharger les journaux de test et exporter le fichier de résultats de test.

Important

Lorsque vous mettez à jour un test, les exécutions de test existantes n’héritent pas automatiquement des nouveaux paramètres du test. Les nouveaux paramètres sont utilisés uniquement par les nouvelles exécutions de test lorsque vous exécutez le test . Si vous réexécutez une exécution de test existante, les paramètres d’origine de l’exécution de test sont utilisés.

Moteur de test

Un moteur de test est une infrastructure informatique gérée par Microsoft qui exécute le script de test. Les instances du moteur de test exécutent le script de test en parallèle. Vous pouvez effectuer un scale-out de votre test de charge en configurant le nombre d’instances de moteur de test. Découvrez comment configurer le nombre d’utilisateurs virtuels ou simuler un nombre cible de requêtes par seconde.

Les moteurs de test sont hébergés dans le même emplacement que votre ressource Azure Load Testing. Vous pouvez configurer la région Azure lorsque vous créez la ressource de test de charge Azure.

Azure Load Testing utilise Standard_D4d_v4 taille des machines virtuelles avec quatre processeurs virtuels, 16 Go de mémoire et système d’exploitation Azure Linux en tant que moteurs de test. Pour les tests basés sur JMeter, les moteurs de test utilisent JDK 21 et Apache JMeter version 5.6.3. Pour les tests basés sur Locust, les moteurs de test utilisent Python 3.9.19 et Locust version 2.33.2.

Pendant l’exécution du script de test, Azure Load Testing collecte et agrège les journaux de l’infrastructure de test à partir de toutes les instances de moteur de test. Vous pouvez télécharger les journaux d’activité pour analyser les erreurs pendant le test de charge.

Composant d’application

Lorsque vous exécutez un test de charge pour une application hébergée par Azure, vous pouvez surveiller les métriques de ressources pour les différents composants d’application Azure (métriques côté serveur). Pendant que le test de charge s’exécute et après l’achèvement du test, vous pouvez surveiller et analyser les métriques de ressources dans le tableau de bord Test de charge Azure.

Lorsque vous créez ou mettez à jour un test de charge, vous pouvez configurer la liste des composants d’application que Azure Load Testing surveillera. Vous pouvez modifier la liste des métriques de ressources par défaut pour chaque composant d’application.

En savoir plus sur les types de ressources Azure pris en charge par Azure Load Testing.

Métriques

Pendant un test de charge, Azure Load Testing collecte les métriques relatives à l’exécution du test. Il existe deux types de métriques :

• Les métriques côté client sont signalées par les moteurs de test. Ces métriques incluent le nombre d’utilisateurs virtuels, le temps de réponse de la demande, le nombre de demandes ayant échoué ou le nombre de requêtes par seconde. Vous pouvez définir des critères d’échec de test en fonction de ces métriques côté client.

• Les métriques côté serveur sont disponibles pour les applications hébergées par Azure et fournissent des informations sur vos composants d’application Azure. Azure Load Testing s’intègre à Azure Monitor, notamment Application Insights et Container Insights, pour capturer les détails des services Azure. Selon le type de service, différentes métriques sont disponibles. Par exemple, les métriques peuvent être pour le nombre de lectures de base de données, le type de réponses HTTP ou la consommation de ressources de conteneur. Vous pouvez également définir des critères d’échec de test en fonction de ces métriques côté serveur.

Contenu connexe

Vous connaissez maintenant les concepts clés d’Azure Load Testing pour commencer à créer un test de charge.

• Découvrez comment fonctionne le test de charge Azure.
• Découvrez comment créer et exécuter un test de charge basé sur l’URL pour un site web.
• Découvrez comment identifier un goulot d’étranglement des performances dans une application Azure.
• Découvrez comment configurer des tests de régression automatisés avec CI/CD.