Concepts clés pour les nouveaux utilisateurs azure Load Testing

Découvrez les concepts et composants clés de Test de charge Azure. 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 des tests 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 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. Pour plus d’informations sur les groupes de threads, consultez la documentation Apache JMeter.

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 du moteur de test.

La formule est la suivante : Nombre total d’utilisateurs virtuels = (utilisateurs virtuels dans le fichier JMX) * (nombre d’instances du moteur de test).

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

Temps de montée en puissance

Le temps de montée en puissance 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 va démarrer 6 secondes (120/20) après que l’utilisateur précédent a démarré.

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 pour rendre la réponse. Le code client, comme du 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)

Demandes par seconde (RPS, Requests Per Second), ou débit, est le nombre total de demandes envoyées à l’application serveur que votre test de charge génère par seconde.

La formule est la suivante : RPS = (nombre de demandes) / (durée totale en secondes).

La durée 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 sur 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 calculer le nombre requis d’utilisateurs virtuels.

La formule est la suivante : 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 de Test de charge Azure

Découvrez les concepts et composants clés de Test de charge Azure. 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 plus haut niveau 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. Test de charge Azure chiffre automatiquement tous les artefacts de votre ressource. Vous pouvez choisir entre des 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 pour accéder à Azure Key Vault pour stocker des paramètres de secret de test de charge ou des certificats. Vous pouvez utiliser une identité managée affectée par le système ou par l’utilisateur.

Test

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 deux façons :

• Chargez un script de test JMeter.
• 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 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.

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

• Paramètres de test de charge, comme des variables d’environnement, des secrets et des certificats.
• Configuration de la charge pour effectuer un scale-out de votre test de charge sur plusieurs instances du moteur de test.
• Critères d’échec pour déterminer quand le test doit être réussi ou en échec.
• Paramètres de supervision pour configurer la liste des composants d’application et des métriques de ressources Azure à superviser pendant la série de tests.

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

Lorsque vous démarrez un test, Azure Load Testing déploie le script de test JMeter, 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 JMeter pour simuler la charge de l’application.

Chaque fois que vous démarrez un test, Test de charge Azure crée une série de tests et l’attache au test.

Série de tests

Une série de tests 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 Apache JMeter. Les instances du moteur de test exécutent le script JMeter en parallèle. Vous pouvez effectuer un scale-out de votre test de charge en configurant le nombre d’instances du moteur de test. Découvrez comment configurer le nombre d’utilisateurs virtuels ou simuler un nombre cible de demandes par seconde.

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

Pendant l’exécution du script de test, Test de charge Azure collecte et agrège les journaux du Worker Apache JMeter provenant des instances du moteur de test. Vous pouvez télécharger les journaux 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 sur Azure, vous pouvez surveiller les métriques des ressources pour les différents composants de l’application Azure (métriques côté serveur). Pendant l’exécution du test de charge et après l’achèvement du test, vous pouvez surveiller et analyser les métriques de ressources dans le tableau de bord de 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 le test de charge Azure surveille. 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, le test de charge Azure collecte des métriques sur l’exécution des tests. Il existe deux types de métriques :

• Les métriques côté client sont rapportées par les moteurs de test. Ces métriques comprennent le nombre d’utilisateurs virtuels, le temps de réponse aux requêtes, le nombre de requêtes ayant échoué et 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. Le service Test de charge Azure s’intègre avec Azure Monitor, y compris 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, il peut y avoir des métriques pour le nombre de lectures de base de données, le type de réponses HTTP ou la consommation de ressources de conteneur.

Contenu connexe

Vous connaissez maintenant les concepts clés du test de charge Azure pour commencer à créer un test de charge.

• Découvrez le fonctionnement du test de charge Azure.
• Découvrez comment créer et exécuter un test de charge pour un site web.
• Découvrez comment identifier un goulot d’étranglement au niveau des performances dans une application Azure.
• En savoir plus sur la manière de Configurer des tests de régression automatisée avec CI/CD.