Fonctionnement : Tests de charge basés sur des objectifs

LoadView Goal-Based Load Test est un outil de test intelligent qui permet de tester par rapport à un nombre cible de transactions, en ajustant automatiquement tous les paramètres de test nécessaires, tels que la charge de l’utilisateur et la durée du test.

Dans LoadView, une transaction représente un script de test (exemple de test) qui peut inclure une ou plusieurs actions de l’utilisateur, telles que l’accès à une page Contactez-nous, le remplissage d’un formulaire et l’envoi. L’objectif de transaction représente le nombre de ces transactions que votre site peut traiter par minute.

L’algorithme de test expliqué

Pour atteindre le nombre souhaité de transactions par minute et tenir compte des fluctuations potentielles des performances du serveur et de l’application cible, LoadView exécute un test en plusieurs cycles. Au cours de chaque cycle, le système effectue les étapes suivantes :

1. Le système vérifie si le nombre généré d’utilisateurs virtuels simultanés correspond à l’objectif de transaction souhaité, compte tenu de la durée moyenne de réponse dans le cycle en cours (durée moyenne de réponse).
2. Si la charge utilisateur générée n’est pas suffisante pour atteindre l’objectif de transaction défini, le système ajuste la charge pour le cycle suivant.

Pour correspondre à l’objectif de transaction spécifié, le nombre initial d’utilisateurs simultanés est calculé en fonction de l’objectif de transaction défini et du temps de réponse mesuré pour la série de tests monoposte exécutée lors de la validation du test :

Charge utilisateur de démarrage = objectif de transaction par minute × durée de la réponse de validation

À la fin du premier cycle de test, le système calcule le nombre réel de transactions par minute pour le cycle. Si ce nombre ne correspond pas à l’objectif de transaction souhaité, la charge d’utilisateurs pour le cycle suivant est ajustée à l’aide de la formule suivante :

Charge utilisateur = objectif de transaction par minute × Avg. Durée de la réponse

Lorsque l’ Avg. Durée de la réponse est calculé comme le temps de réponse moyen mesuré pour le cycle en cours. Pour garantir la précision, le script de test est exécuté plusieurs fois au cours de chaque cycle, le nombre d’exécutions étant défini par le paramètre de test Taux d’ajustement .

Ce processus itératif d’évaluation de l’objectif de transaction et d’ajustement de la charge se poursuit jusqu’à ce que la durée de test prédéterminée soit écoulée.

Exemple concret

Pour expliquer comment cela fonctionne dans la vie réelle, examinons le rapport ci-dessous où l’objectif de transaction est défini sur 2 000 transactions par minute (TPM) et la charge d’utilisateur de départ recommandée est de 377 utilisateurs virtuels simultanés.

Premier cycle : Évaluation initiale

Au cours du premier cycle de test, LoadView a atteint 1 176 TPM, ce qui n’est pas le cas de l’objectif de 2 000 TPM. Le temps de réponse moyen (durée moyenne de réponse) enregistré était de 19,39 secondes. Sur la base de ces données, le système recalcule la charge utilisateur requise pour le cycle suivant à l’aide de la formule :

Charge utilisateur₂ = (2 000 / 60) × 19,39 ≈ 646 utilisateurs virtuels simultanés

Deuxième cycle : Ajustement de la charge utilisateur

Au cours du deuxième cycle, la charge utilisateur est passée à 646 utilisateurs virtuels simultanés. Cependant, le temps de réponse du serveur cible a commencé à augmenter (comme indiqué par la première flèche sur le graphique Temps de réponse). Cette augmentation a entraîné une augmentation de la durée moyenne de réponse de 32,39 secondes.

Malgré l’augmentation de la charge utilisateur, le système n’a atteint que 1 176 TPM. Cela indique que le taux de transaction ne s’est pas amélioré avec la charge supplémentaire.

Troisième et quatrième cycles : autres ajustements et observations

LoadView a recalculé la charge utilisateur pour le troisième cycle :

Charge utilisateur₃ = (2 000 / 60) × 32,39 ≈ 1 079 utilisateurs virtuels simultanés

Au cours du troisième cycle, le temps de réponse a continué à croître proportionnellement à l’augmentation de la charge des utilisateurs. Au cours du quatrième cycle, le temps de réponse du serveur a continué d’augmenter avec la charge des utilisateurs, suivant les tendances observées lors des cycles précédents. Ce modèle suggère que les performances du serveur se dégradaient à mesure que d’autres utilisateurs étaient ajoutés, empêchant LoadView d’atteindre l’objectif de transaction souhaité.

Cet exemple montre qu’une augmentation significative du temps de réponse, même avec une charge utilisateur plus élevée, peut indiquer des problèmes de performances de serveur ou d’application qui doivent être résolus pour atteindre l’objectif de transaction souhaité.