Analyse des résultats des tests de résistance

Chaque jour dans le monde, il existe de plus en plus d'outils pour réaliser des tests de résistance. En fait, l'intérêt même pour ce sujet commence à croître.

La tâche principale d'un outil de test de charge est d'appliquer une charge donnée au système. Mais en plus de cela, il y a une tâche supplémentaire, non moins importante: fournir un rapport sur les résultats de la soumission de cette charge. Sinon, nous effectuerons des tests, mais nous ne pourrons rien dire sur son résultat et ne pourrons pas déterminer avec précision à partir de quel moment la dégradation du système a commencé.



Les outils de test les plus populaires pour le moment sont Gatling, MF LoadRunner, Apache JMeter. Tous ont la possibilité de générer des rapports prêts à l'emploi sur les tests effectués, ainsi que des graphiques individuels ou des données brutes, sur la base desquels le rapport lui-même est construit.







Avant de rédiger un rapport, vous devez comprendre pour qui nous le rédigeons et dans quel but nous poursuivons. Cela n'a aucun sens d'ajouter de nombreux graphiques du temps de réponse de l'application au rapport pour chaque opération si votre objectif est de déterminer s'il y a des fuites de mémoire, si une opération instable a été corrigée lors d'un test de fiabilité ou si vous devez comparer deux versions l'une par rapport à l'autre dans le cadre d'un test de régression. Pour répondre à ces questions, vous n'avez besoin que de quelques graphiques, sauf si, bien sûr, vous avez résolu les problèmes et ne voulez pas les comprendre. Par conséquent, avant de créer un rapport, demandez-vous si vous devez vraiment y ajouter tous les graphiques ou seulement les plus indicatifs et donnez une réponse à l'objectif du test. De plus, l'ensemble des graphiques et leur analyse pour le rapport dépendent du modèle de charge sélectionné - fermé ou ouvert,puisque différents modèles donneront des chiffres différents sur les graphiques.



Chez Tinkoff, nous utilisons activement l'outil Gatling.Par conséquent, en utilisant son exemple, nous vous dirons comment créer un rapport de vos rêves et où regarder lors de son analyse. Je tiens également à noter tout de suite que presque tous les graphiques décrits dans l'article peuvent être obtenus en ligne à l'aide d'un ensemble de votre outil avec Grafana. Il s'agit de l'outil le plus pratique pour créer des rapports à la volée, à l'aide d'un tableau de bord préconfiguré. De plus, il vous permet de créer plus rapidement presque tous les graphiques en fonction des données que vous envoyez. Il existe déjà des tableaux de bord prêts à l'emploi pour presque tous les outils de test de charge. Des graphiques pour d'autres outils - MF LoadRunner et Apache JMeter - seront également donnés, leur analyse est construite par analogie avec Gatling.

Métriques de base

Indicateurs

Affiche la distribution quantitative et en pourcentage du temps de réponse aux demandes par groupe. Les graphiques de ce type sont pratiques à utiliser pour donner une évaluation préliminaire rapide des résultats du test sans une analyse plus approfondie du reste des graphiques.



Les seuils de groupe à groupe sont prédéfinis en fonction de l'examen par les pairs ou du SLA (exigences non fonctionnelles). Par exemple, il peut y avoir trois groupes:

• excellent - temps de réponse inférieur à 50 secondes;
• moyen - plus de 50, mais moins de 100 secondes;
• terrible - plus de 100 secondes.

Dans Gatling, vous pouvez configurer vous-même les seuils de passage de groupe en groupe et leur numéro dans le fichier gatling.conf. Il est préférable de créer des graphiques de ce type en fonction de la méthodologie. APDEX (Application Performance Index)

Vous pouvez également ajouter un indicateur avec le nombre / le pourcentage de requêtes ayant échoué.







La méthode APDEX vous permet d'utiliser des indicateurs dans les tests de régression pour comparer les versions: de cette façon, vous pouvez immédiatement voir à quel point la version est devenue pire ou meilleure en général. Malheureusement, ce graphique n'est pas prêt à l'emploi dans MF LoadRunner et Apache JMeter, mais il est facile de le créer à l'aide du tableau de bord Grafana.

Tableau des temps de réponse

Par défaut, Gatling crée une table basée sur les percentiles, les temps de réponse moyens et maximums et les erreurs. Il suit le dépassement du SLA (excès d'exigences non fonctionnelles). En règle générale, les SLA indiquent les percentiles 95, 99 et le pourcentage d'erreurs. Ainsi, le tableau vous permet d'obtenir une évaluation rapide des résultats du test.



Si vous regroupez les requêtes en tant que transactions, vous pouvez voir dans le tableau à la fois le score pour les requêtes individuelles et le score pour l'ensemble du groupe et de la transaction à la fois.

Graphique des utilisateurs virtuels

Habituellement mesuré en morceaux et montre comment les utilisateurs entrent dans l'application, illustrant ainsi le profil de charge réel. Il convient de noter tout de suite que pour MF LoadRunner et Gatling, ces graphiques montrent le nombre d'utilisateurs virtuels et pour Apache JMeter - le nombre de threads.



Le graphique est utilisé pour contrôler l'exactitude de l'application de charge. Il est nécessaire que votre scénario de conception corresponde à ce que vous avez soumis au système dans la réalité. Par exemple, si vous voyez de grands écarts à la hausse par rapport au scénario prévu sur le graphique, cela signifie que quelque chose s'est mal passé: une erreur dans le calcul, plus de copies de l'outil de chargement ont été lancées que nécessaire, et ainsi de suite. Il est peut-être inutile d'analyser d'autres graphiques, puisque vous avez soumis 100 utilisateurs de plus que prévu et que le système a été conçu à l'origine pour fonctionner avec seulement 10 utilisateurs.

Ce graphique est divisé en deux types:

• Utilisateurs actifs affiche le nombre de threads actuellement actifs par seconde. Lorsque les threads démarrent et s'arrêtent, en particulier dans un modèle à charge ouverte, ce taux fluctuera tout au long du test.
• Total VUsers indique le nombre total de threads démarrés et arrêtés depuis le début des tests. Pratique pour un modèle à charge fermée dans lequel les fils ne meurent pas.

Le type de graphique dépend également du modèle de charge:

• Modèle fermé - les utilisateurs doivent se connecter au système en fonction du profil de charge prévu. Si le graphique montre des creux ou des pics, cela indique que la charge ne s'est pas déroulée selon le scénario calculé ou prévu et nécessite une étude plus approfondie.
• — , . , . , , / . , — .

Response Time

Le plus souvent mesuré en millisecondes - il indique le temps de réponse aux demandes adressées à l'application. Le temps de réponse ne doit pas dépasser le SLA. Ce graphique est le principal outil pour trouver les points de dégradation lors des tests de charge.



Si des pics sont visibles sur le graphique, cela signifie qu'à ce moment, l'application n'a pas répondu pour une raison quelconque - cela peut être un point de départ pour d'autres recherches. Le temps de réponse doit être uniforme, sans pics pour toutes les opérations tout au long de l'étape de charge, et également en corrélation avec l'entraînement de la charge. Gatling n'inclut pas de graphique du temps de réponse «net» (moyen, non agrégé), contrairement à d'autres outils.



En plus du graphique du temps de réponse de chaque requête, il est également pratique d'afficher une ligne avec le temps de réponse total. En superposant le tracé de charge appliquée (VU / RPS), vous pouvez suivre la corrélation avec l'augmentation du temps de réponse à partir de l'augmentation de la charge appliquée (VU / RPS). Apache JMeter appelle ce graphique Temps de réponse vs Threads.



Ensuite, il y aura des graphiques, sur lesquels il peut y avoir plusieurs lignes, chacune affichant son propre scénario ou requête. Si vous avez un test complexe avec de nombreuses opérations et un profil non linéaire, nous vous recommandons d'afficher uniquement les requêtes ou groupes de requêtes les plus représentatifs dans le rapport. Sinon, vous ne pouvez refléter que les demandes qui dépassent le SLA / SLO, afin de ne pas encombrer le calendrier et le rapport.

Variations de graphique

Une modification est possible dans laquelle les centiles de temps de réponse sont appliqués et une ligne de temps de réponse moyen pour toutes les demandes est ajoutée. L'utilisation des percentiles ici sera plus correcte, car le temps de réponse moyen est très sensible aux valeurs aberrantes.



Dans les tests de performance, les 95e et 99e centiles sont le plus souvent utilisés pour plus de clarté. Cependant, si vous regardez le temps de réponse moyen, vous devez tenir compte de l'écart-type (quadratique moyenne).

Répartition du temps de réponse

Il existe également d'excellents graphiques montrant la dépendance de la distribution du temps sur le nombre de demandes.



Ce type de graphique est quelque peu similaire aux indicateurs, mais montre une image plus complète de la distribution du temps, sans découpage par percentiles ou autres agrégats. À l'aide du graphique, vous pouvez définir plus clairement les limites des groupes d'indicateurs. MF LoadRunner n'a pas un tel calendrier.

Latency

À partir de cette métrique, un paramètre supplémentaire Latency (millisecondes) peut également être distingué - le temps de latence (le plus souvent, cela est compris comme la latence du réseau). Ce paramètre indique le temps entre la fin de l'envoi de la demande et la réception du premier paquet de réponse du système.

En utilisant ce paramètre, vous pouvez également mesurer la latence au niveau du réseau si le paramètre augmente. Il est souhaitable qu'il tende vers zéro. Ce type de graphique et le suivant sont principalement utilisés pour une analyse approfondie et pour trouver des problèmes de performances. Ce graphique n'est pas prêt à l'emploi à Gatling. Dans MF LoadRunner, ce graphique est appelé Graphique de latence moyenne dans le bloc Graphiques de virtualisation de réseau si vous avez installé des agents de surveillance.

Bande passante

De la même manière que la métrique ci-dessus, vous pouvez sélectionner le paramètre Bandwidth (kilobits par seconde) - la bande passante du canal. Il montre la quantité maximale de données pouvant être transférées par unité de temps.



En modifiant ce paramètre sur l'outil de chargement, vous pouvez simuler différentes sources de connexions à l'application: mobile 4G ou réseau filaire. La version gratuite de Gatling ne possède pas ce graphique, il n'est disponible que dans la version payante de Gatling FrontLine. Ce graphique n'est prêt à l'emploi que dans MF LoadRunner, il est situé dans le même bloc que Latency et s'appelle Graphique d'utilisation moyenne de la bande passante.

Tableau de demande par seconde

Mesuré en morceaux par seconde - indique le nombre de demandes entrant dans le système en 1 seconde.



Le graphique montre le nombre de requêtes que votre système peut traiter sous charge, et c'est également le graphique principal pour la création du rapport. Il suit également le dépassement du SLA, car avec une augmentation de la charge lors du passage du point de dégradation ou des extrema locaux, une défaillance peut être observée, puis une forte augmentation. Le plus souvent, cela est dû au fait que lorsque l'application commence à se dégrader, les requêtes commencent également à s'accumuler à l'entrée de l'application (une file d'attente apparaît), puis l'application leur donne une sorte de réponse ou les requêtes tombent avec le délai d'expiration, ce qui provoque une forte augmentation du graphique - parce que la réponse a été reçue.

1. VU, RPS/TPS , .
2. Response Time, , .

TPS

Il est mesuré en morceaux par seconde et indique le nombre de transactions (il peut y avoir de nombreuses demandes dans une transaction) en 1 seconde.



Par exemple, la transaction «entrer dans votre compte personnel» comprend les demandes suivantes: ouverture de la page principale, saisie d'un login, mot de passe, appui sur le bouton «envoyer», redirection vers la page d'accueil - par unité de temps. Dans Gatling, un graphique ne peut être obtenu qu'en utilisant Grafana, car pour les groupes dans un rapport HTML, les graphiques sont construits uniquement en fonction du temps de réponse.

Tableau des erreurs

Habituellement mesuré en taux (pièces par seconde) - le graphique montre l'augmentation du nombre de demandes erronées. Il est également pratique de mesurer la valeur en pourcentage du nombre total de demandes. Ce graphique suit le SLA hors limites en fonction du nombre ou du pourcentage d'erreurs.



Si vous superposez le graphique Temps de réponse, vous pouvez voir comment une augmentation des erreurs affecte une augmentation du temps de réponse de l'application.



Gatling par défaut n'a pas de graphique séparé montrant uniquement les erreurs. Dans Gatling, il est combiné avec le graphique VU et montre immédiatement comment une augmentation de la charge affecte une augmentation du nombre d'erreurs, et aide à détecter le seuil à partir duquel le SLA est dépassé ou des erreurs apparaissent. Apache JMeter n'a pas non plus de planning séparé, il est combiné avec les graphiques du nombre de transactions.

État des réponses HTTP

Il est également possible de tracer la distribution du nombre d'erreurs par codes de réponse d'application sur un graphique - il est pratique à utiliser pour classer les erreurs.



Par exemple, si vous avez obtenu 100% sur le graphique précédent, vous commencez à analyser les erreurs 50x dues au fait que le serveur ne répond pas, ou 403 en raison du fait que le pool est incorrect et que les utilisateurs ne peuvent pas se connecter, si, par exemple, vous utilisez le protocole HTTP.

Dans un premier temps, la version gratuite de Gatling ne possède pas cette carte, elle n'est disponible que dans la version payante de Gatling FrontLine. Pour que le graphique apparaisse dans la version gratuite, vous devez reconfigurer le logback.xml afin que les journaux soient collectés dans le graylog, et y créer le graphique requis.

Graphique de débit

Il est généralement mesuré en bits par seconde. Le graphique montre le débit de l'application, à savoir la quantité de données envoyées et traitées par l'application par unité de temps.

Il est généralement utilisé pour une analyse approfondie d'un problème d'application. Gatling ne contient ce graphique que dans FrontLine, il n'est pas dans la version gratuite.

Modifications possibles

1. Response Time, , (Throughput). Response Time, Throughput , : - .
2. Bandwidth, , .
3. VU, , , . .

La plupart des graphiques peuvent être obtenus en utilisant les rapports Gatling basés sur HTML après le test, ou en configurant le bundle de surveillance Graphite-InfluxDB-Grafana . Pour l'affichage, vous pouvez utiliser un tableau de bord prêt à l'emploi de la bibliothèque de tableaux de bord https://grafana.com/grafana/dashboards/9935 .



Lors de l'analyse et de la compilation de vos tableaux de bord pour Gatling, vous devez tenir compte du fait que les résultats dans InfluxDB sont stockés agrégés et ne conviennent que pour une évaluation préliminaire des résultats NT. Il est recommandé après le test de recharger le fichier simulation.log dans la base de données et de créer un rapport final dessus et de rechercher les problèmes de performances du système.

Description de la matrice des métriques

Tout ce que nous avons décrit ci-dessus est présenté sous la forme d'une petite tablette résumant toutes ces connaissances.