Ceux qui ont déjà exécuté des tests de charge, savent que la machine cliente (celle qui simule les utilisateurs) est aussi importante que le serveur testé. Si la machine cliente est incapable de simuler correctement le nombre d’utilisateurs voulu à cause d’un processeur trop faible, d’un manque de mémoire vive, d’un disque dur trop lent, le serveur ne sera pas suffisament stressé et les résultats seront faussés.
Une première solution serait donc d’avoir une machine sur-dimensionnée dédiée uniquement aux tests de charge. Reste que dimensionner correctement une telle machine peut s’avérer difficile et est dépendante de l’outil de tests utilisé et du mode d’utilisation (interface graphique ou ligne de commande). C’est d’autant plus vrai lors des tests de charge aux limites où les demandes en ressources (CPU, RAM, HD, …) seront de plus en plus importante. Si la machine de tests craque avant le serveur, il ne reste plus qu’à investir dans du nouveau matériel.
Apache JMeter propose une alternative : le déclenchement de tests à distance. Il s’agit de mutualiser les ressources de plusieurs machines d’un même réseau pour exécuter un test JMeter. Le déclenchement se fait de façon synchronisée depuis une des machines, soit via l’interface graphique de JMeter, soit par ligne de commande.
Concrètement, l’opération se fait en 3 étapes :
- Démarrage de serveurs RMI JMeter sur chaque machine “esclave”
- Enregistrement des noms réseaux (ou adresses IP) sur la machine “maître”
- Déclenchement du test depuis la machine “maître” (interface graphique ou ligne de commande)
Note 1 : La machine “maître” peut également être “esclave”.
Note 2 : Attention aux firewalls entre les machines du réseau. Le port RMI par défaut (1099) peut être modifié.
Conclusion : Quand vous n’avez à votre disposition que des machines moyennes pour stresser un super-serveur, pensez à mutualiser leurs ressources avant d’envisager l’achat d’une nouvelle machine.
Pour les détails sur ce sujet, jetez un oeil sur le manuel utilisateur de JMeter.
