Voici une check-list qui pourrait vous éviter quelques déconvenues (genre test de charge raté) si vous la déroulez juste avant de lancer votre test de charge.
- Vérifier que les éléments Groupe d’unités sont corrects, à savoir le bon nombre d’unités, la bonne montée en charge, le nombre d’itérations ou la bonne durée.
- Vérifier les éléments Compteurs de temps : est-ce que c’est la bonne valeur de temps de pause, ou de débit constant ?
- Vérifier que vous n’avez pas oublié de mettre un Récepteur pour enregistrer au format CSV un fichier de vos temps de réponses (ou bien ne pas oublier le « -l » dans la ligne de commande).
- Vérifier que les fichiers CSV servants de sources de données sont corrects et ont bien les valeurs nécessaires pour le test
- Vérifier les Variables pré-définies : est-ce les bonnes pour votre test de charges ?
- Vérifier que les éléments de configuration « Par défaut », genre celui du http : « Paramètres HTTP par défaut » a bien la bonne valeur pour le site web, le port, s’il faut récupérer les ressources incluses, etc.
- Vérifier que vous avez pensé à mettre des éléments Assertion dans votre scénario afin de vérifier que le résultat attendu sera bien celui reçu.
- Vérifier que la petite case à cocher « Inclure la durée des compteurs de temps dans le calcul du temps » dans les Contrôleurs de Transaction est bien décochée. Malheureusement par défaut, elle est cochée et donc les temps de réponses peuvent être faussés si vous avez placé des éléments Compteurs de temps en fils.
- Vérifier que vous avez placé un Récepteur configuré pour enregister un fichier en mode JTL (XML) avec toutes les cases à cocher du bouton Configurer : cochées, et avec la case « Uniquement les erreurs » de cocher. Cela vous permettra d’avoir un fichier de résultats uniquement pour les erreurs captées avec tous les détails (requête, données de réponses) afin de mieux comprendre ensuite les problèmes survenues.
- Vérifier que la machine de test qui exécutera JMeter n’est pas déjà surchargée (CPU déjà utilisée, pas assez de mémoire, disque dur quasiment plein, réseau saturé, etc.) avant lancer votre tir.
En bonus, 7 autres points de vérification « conditionnels » :
- Si vous avez plusieurs Groupes d’unités dans votre arbre, vérifier s’ils doivent être lancés en série ou en parallèle. Configurable via l’option « Lancer les groups d’unités en série » dans l’élément Plan de test.
- Si vous lancez votre tir en mode graphique (pas vraiment recommandé), désactivez les Récepteurs Arbre de résultats. Ils sont bien trop gourmands en mémoire.
- Si c’est un « gros » test de charges, avez-vous pensé à augmenter la mémoire Java allouée à JMeter ? Plus il y a d’utilisateurs virtuels, plus il faudra de mémoire Java (et aussi d’injecteurs puissants)
- Si votre JMeter opère sous Unix/Linux, vérifiez les valeurs de « max open files » (via ulimit -n). Généralement la valeur par défaut est bien trop petite et va limiter JMeter dans la création de fichiers (pour rappel, sous Unix/Linux, tout est un fichier y compris les connexions tcp/ip)
- Si vous lancez le tir en mode non-gui (le bon choix), activez le « résumé statistiques », c’est toujours sympa de suivre un peu ce qui se passe.
- Si vous avez conçu un test de charge en utilisant l’option IP Source dans les requêtes HTTP afin d’avoir plusieurs flux IP différents, vérifier que les adresses IP sont bien configurées sur l’injecteur JMeter (via la technique de l’IP aliasing), et aussi que le fichier CSV contenant les IP est correct.
- Si vous effectuez un tir de charge de longue durée lancé à distance via SSH (ou Telnet!), ne pas oublier de mettre le fameux « nohup » devant la commande de lancement : exemple : nohup ./jmeter -t /home/user/monscript.jmx -l /home/user/resultats.csv & Le nohup permettra au tir de continuer même si la connexion réseau est coupée.
La liste n’est pas exhaustive, mais devrait éviter quelques écueils.
Vous pouvez aussi partager vos points de vérification sur le groupe JMeter en français.
Bon courage dans vos tests de charge.