JMeter : Pourquoi exécuter son test de charges en mode non-gui (sans interface graphique) ?

JMeter dispose de deux modes de fonctionnement, un mode GUI et un non-GUI, « GUI » signifiant Graphical User Interface, c’est-à-dire un mode de fonctionnement avec une interface graphique utilisateur qui permet de créer, éditer un script et lancer un test de charges et autres choses. Le mode non-GUI ne permet pas de manipuler un script, mais simplement de lancer le script de test de charges.

Pourquoi ce mode non-GUI ? Parce qu’en mode GUI, JMeter peut être gêné par la gestion du ‘graphisme‘ pendant qu’il est en train d’exécuter un test de charges. Et cela peut avoir un impact sur la qualité des résultats du tir.

En effet, sur le poste JMeter, la gestion du mode graphique impacte :

• Le processeur. JMeter doit traiter deux choses : le test de charges (envoi des requêtes, réception des réponses, éventuellement écriture dans un fichier, etc.) et l’affichage des résultats dans les récepteurs (listeners) ainsi que d’éventuels calculs statistiques (total, moyenne, etc.). La puissance du processeur est donc découpée en deux tâches principales : la gestion du tir et la gestion de l’affichage.
• La mémoire. Certains récepteurs comme celui de l’arbre de résultats ou celui de tableau de résultats, sont extrêmement gourmands en mémoire, en effet, pour chaque test d’échantillon, il faut ajouter un petit ‘chouia‘ dans la mémoire. Or quand son test de charge génère de très nombreuses requêtes, le petit chouia devient énorme, ce qui peut même faire des OutOfMemoryError du côté JMeter si on ne prends pas soin d’augmenter la taille de mémoire maximale de la JVM de JMeter (au niveau du script de lancement).

Et pour couronner le tout, la machine virtuelle Java (qui je le rappelle, exécute JMeter), aura parfois besoin de faire passer le garbage collector (GC) pour la gestion de la mémoire, ce qui a un impact sur le traitement des résultats, le GC gelant les threads (donc le tir et le traitement des résultat) lors de l’identification des objets à supprimer de la mémoire.

Ces points montrent que le mode GUI est plutôt à proscrire lors d’un test de charge aussi simple soit-il, car on risque d’avoir des résultats erronés en termes de calcul de temps de réponses, par JMeter lui-même, ce dernier est perturbé par la gestion de l’affichage des résultats de manière graphique, et par le fonctionnement de la JVM au niveau la gestion de la mémoire si le nombre de requêtes/réponses devient très important.

Donc pour résumé, le mode GUI est plutôt à utiliser pour créer et maintenir ses scripts JMeter et lancer des tir de charges « blancs » permettant de vérifier la bonne exécution d’un scénario. Le mode non-GUI est à utiliser pour l’exécution du test de charge « officiel ».

Un petit conseil pour finir : si vous avez une machine JMeter avec un processeur multi-core (dual core), il est préférable d’utiliser une machine virtuelle Java dernière version (6), car la gestion des processeurs (core) y est bien plus optimale que la version 5 (sans parler de la 1.4). Avec une JVM 6, JMeter et tous ses petits threads vont utiliser l’ensemble des CPU disponibles sur le poste de test JMeter.