Vous trouverez un résumé d’un test de charge terminé sur la page Rapport de test sous l’onglet Résumé .

contour

En haut de la page du rapport, vous trouverez un aperçu des résultats du test et des informations générales sur le test. L’indicateur d’état du test représente le ratio de sessions de test exécutées avec succès par rapport aux sessions avec des erreurs. Pour afficher les détails des sessions ayant échoué, accédez à l’onglet Sessions et filtrez la liste des sessions en fonction de l’état Échec .

Pour télécharger la liste des injecteurs de charge instanciés pour le test avec les adresses IP correspondantes, dans la section Rapport Informations générales , cliquez sur Exporter au format CSV.

Vue d’ensemble des graphiques

L’axe vertical des Y de chaque graphique représente les paramètres d’exécution des tests, en fonction du type de graphique. L’axe X horizontal affiche le temps de durée du test en quelques minutes.

Plan d’exécution

Le graphique en ligne montre la variation du nombre réel d’utilisateurs virtuels au cours de la période de test par rapport au nombre prévu d’utilisateurs virtuels en fonction du scénario de test. Vous pouvez voir si le plan d’exécution du test, en termes de charge utilisateur, a été implémenté avec succès.

L’axe Y représente le nombre d’utilisateurs virtuels.

Les lignes suivantes sont affichées sur le graphique :

  • max. Utilisateurs virtuels – le nombre maximal prédéfini d’utilisateurs virtuels pouvant être simulés en même temps sur la ressource cible.
  • Utilisateurs virtuels réels – le nombre d’utilisateurs réellement simulés sur la ressource cible par intervalle de temps. Chaque nœud représente le nombre total d’utilisateurs simulés au cours d’une période donnée. Le premier nœud représente le nombre de départ d’utilisateurs.
  • Utilisateurs virtuels attendus – affiche le changement prévu dans le nombre d’utilisateurs pour atteindre la charge maximale prévue.

Si la ligne Utilisateurs virtuels réels atteint la ligne Nombre maximal d’utilisateurs virtuels, tous les utilisateurs virtuels alloués au test ont été utilisés et le site a été testé sous la charge maximale planifiée. D’autre part, un problème se produit s’il y a un écart important entre ces deux lignes, comme le montre l’image ci-dessous.

Plan d’exécution du test de charge

Les raisons les plus fréquentes pour lesquelles la valeur Nombre maximal d’utilisateurs virtuels n’a pas été atteinte sont les suivantes :

  • Les LI atteignent une limite d’utilisation du processeur. Vérifiez le tableau de charge de l’injecteur de charge dans le rapport de test.
  • Dans le cas des tests basés sur les objectifs, l’objectif de transaction a été atteint avec le nombre d’utilisateurs inférieur à celui spécifié par Max Virtual Users. Consultez le graphique transactions par minute dans le rapport de test.

Transactions par minute (Test de charge basé sur les objectifs uniquement)

Le graphique reflète l’objectif par rapport au nombre réel de transactions par minute à chaque itération de test.

L’axe Y représente le nombre de transactions exécutées par minute sur la ressource cible.

Le graphique montre les lignes suivantes :

  • Transactions (planifiées) : nombre planifié de transactions par minute défini dans le scénario de test.
  • Transactions (réelles) – le nombre réel de transactions simulées sur le site Web cible à chaque itération. La ligne comporte des espaces qui indiquent les périodes d’étalonnage.
  • Périodes d’étalonnage – un temps nécessaire pour atteindre le niveau de charge suivant. Les périodes d’étalonnage sont affichées sous forme d’intervalles grisés entre les périodes de charge réelle.

 

Test de charge basé sur les objectifs de transaction

Si l’objectif n’a pas été atteint alors que la ligne Utilisateurs virtuels réels du graphique Plan d’exécution chevauche la ligne Nombre maximal d’utilisateurs virtuels , augmentez la valeur Nombre maximal d’utilisateurs simultanés dans le scénario de test et répétez le test.

Temps de réponse

Le graphique du
temps de réponse
montre l’évolution de la durée moyenne réelle des transactions et du 90e centile associé.

Le 90e centile indique que 90 % des transactions de test ont un temps de réponse égal ou inférieur à la valeur de temps de réponse de 90 % fournie sur le graphique.

L’axe Y représente le temps en quelques secondes. Chaque nœud du graphique représente la valeur du temps de réponse calculée pour l’intervalle correspondant.

S’il n’y a pas de fluctuations de ligne significatives sur le graphique, votre site Web a géré la charge de test avec succès.

Si vous avez remarqué une croissance ou une baisse spectaculaire du temps de réponse au cours du test ou un pic marqué, consultez les autres graphiques pour plus de détails. Par exemple, sur les graphiques ci-dessous, une croissance spectaculaire du temps de réponse causée par une augmentation progressive du nombre de sessions comportant des erreurs.

Temps de réponse vs échecs des sessions de test

Statistiques de session

Le graphique Sessions démarrées permet de comparer le nombre total de sessions démarrées et le nombre de sessions échouées/réussies. L’axe Y indique le nombre de sessions.

Une session comprend un lancement/arrêt du navigateur et une transaction par lui-même.

Sur le graphique, vous pouvez trouver les lignes suivantes:

  • Sessions commencées – le nombre total de sessions commencées à un intervalle de temps donné.
  • Sessions de réussite – le nombre de sessions qui ont été exécutées sans erreur, c’est-à-dire que toutes les demandes de cibles de test ont été exécutées avec succès.
  • Sessions ayant échoué – le nombre de sessions avec des échecs (aucun mot-clé/image trouvé, échec de l’accès à la ressource cible, etc.).
  • Sessions inachevées – le nombre de sessions qui ont été abandonnées automatiquement à la fin de la durée du test. Pour plus d’informations sur ce type de sessions de test de charge, consultez l’article Sessions inachevées de notre base de connaissances.

Le graphique Sessions cumulées indique le nombre total de sessions démarrées au cours du test. Le graphique permet aux utilisateurs de LoadView d’évaluer le nombre total d’utilisateurs virtuels simulés sur la ressource cible au cours de la période de test. L’axe Y indique le nombre de sessions.

Chaque nœud représente le nombre total, calculé comme une somme de sessions commencées au moment du calcul.

Le graphique à points Erreurs par type d’erreur illustre le nombre de sessions d’erreur par type d’erreur . Le nombre est spécifié sur l’axe Y.

Utilisez le graphique pour déterminer quels types d’erreurs prédominaient au cours d’un moment spécifique. Accédez à l’onglet Sessions pour examiner les échecs. Pour obtenir des descriptions d’erreur, cochez Codes d’erreur.

Charge injecteur de charge

Le graphique montre les mesures de charge CPU reçues de Dotcom-Monitor LIs. Utilisez-le pour évaluer comment votre test affecte les performances des IG exécutant le test à partir de différentes zones géographiques.

Assurez-vous que les niveaux de charge des IG ne sont pas supérieurs à 80 %. Sur la base de notre expertise, la charge cpu optimale pour la machine Load Injector Server est de 80% ou moins. Ce niveau de charge exclut les retards matériels du serveur qui influencent les performances du serveur et ralentissent le traitement des données.

Si la charge CPU des IG dépasse 80 %, il est recommandé de diminuer la valeur de charge utile et de répéter le test. Sinon, le test continuera à montrer des résultats inexacts.

D’autre part, si le niveau d’utilisation du Processeur est faible, vous pouvez augmenter la charge utile par injecteur de charge et le nombre maximum d’utilisateurs virtuels pour utiliser les ressources LoadView de manière optimale et minimiser le coût.

Conseils sur l’interprétation des résultats

Toutes les cartes sont synchronisées les unes avec les autres par l’axe du temps, de sorte que les lignes verticales sur les graphiques sont alignées. Par conséquent, vous pouvez examiner l’historique d’exécution du test d’un graphique à l’autre et voir comment le nombre d’utilisateurs simulés influe sur le temps de réponse et la charge du Processeur LIs à une période donnée. Dans l’exemple ci-dessous, l’agent de liaison n’a pas été en mesure de générer des demandes et d’accepter les réponses du site Web assez rapidement car il simulait trop d’utilisateurs virtuels et l’utilisation du processeur était maximale.

CPU Loaad vs temps de réponse vs charge

Nœuds sur les graphiques sont actifs, donc en cliquant sur un nœud va ouvrir son infotip. Pour voir des informations détaillées pour les sessions liées aux nœuds, cliquez sur Afficher les détails au bas de l’infotip. Les rapports de session pour la période sélectionnée seront affichés sous l’onglet Sessions.

Pour faciliter l’analyse d’un graphique et filtrer les lignes dessus, utilisez les commutateurs à côté des graphiques.