Le test de charge sans passer par Jmeter : Locust, Selenium, ou Gatling?

Un test de charge consiste à évaluer la capacité d’une application à gérer une charge réaliste ou importante sur son infrastructure. C’est l’un des tests les plus importants pour les services Web, bien qu’il soit souvent mis de côté au profit des tests fonctionnels, plus prisés par les développeurs.   

Dans le cadre d’un de nos projets, nous avons priorisé les tests de charge après une refonte et un réusinage majeurs de l’infrastructure de notre client. Ce client, en l’occurrence, offre un service qui aide des milliers d’utilisateurs à se connecter à différentes institutions pour consulter et gérer leurs comptes de facturation. 

Critères du test de charge

Nous avions à tester, entre autres, le parcours utilisateur consistant à se connecter et télécharger une facture au format PDF. L’application utilise des scripts pour récupérer des informations à partir de nos points de terminaison API REST et les présente à l’utilisateur pour interaction. 

Compte tenu de la nature de cette fonctionnalité, il ne suffit pas d’effectuer un test de charge sur des pages statiques. Il faut : 

• simuler la connexion d’un utilisateur; 
• imiter l’activité d’un utilisateur; 
• et déterminer le nombre d’utilisateurs que le système peut supporter à un instant donné.  

Notre ancienne solution : tester la charge avec JMeter 

Nous avions déjà effectué des tests de charge à l’aide de JMeter, une véritable référence du domaine, mais notre équipe n’était pas convaincue du résultat. L’impression générale était que l’outil était lourd, pénible à configurer et à démarrer, gourmand en ressources et généralement peu convivial pour les développeurs.  

Les inconvénients de JMeter

Malgré son statut de référence en code source libre depuis des décennies et ses nombreuses fonctionnalités, JMeter présente de nombreux inconvénients : 

• La version de base n’offre que le minimum syndical. 
• Des extensions sont nécessaires dès que l’opération requise est un tant soit peu complexe. 
• Obsolète du point de vue de la compatibilité DevOps (excepté une compatibilité limitée pour la plateforme de SaaS Blazemeter). 
• Peu convivial pour les développeurs, la planification des tests passant exclusivement par son interface graphique poussive et incommode. 

Nos idées : Le test de charge sans passer par Jmeter

Après la refonte complète de l’infrastructure et des applications de notre client, nous avons dû créer de nouveaux plans de tests pour simuler correctement l’activité des utilisateurs sur des pages dynamiques. Face aux limitations de JMeter, nous avons exploré et sélectionné d’autres solutions : Selenium, Gatling et Locust.

Selenium

Selenium est ce qu’on appelle un navigateur « sans-tête » : il est dépourvu d’interface graphique, mais permet d’automatiser la navigation et les tests de pages Web. Cette option a été retenue pour garantir l’exécution de l’activité utilisateur simulée sur les pages dynamiques. De cette manière, nous pouvons interagir avec les différents boutons et jetons de sécurité HTML lors du chargement de la page. Brève introduction à Selenium :

• Navigateur sans-tête
• Code source libre
• Conçu pour les applications Web
• Capable de réaliser des tests parallèles et distribués 

Les avantages de Selenium :

• Conçu pour tester des applications Web et vérifier les éléments de l’interface utilisateur.
• En tant que navigateur sans-tête, il permet au développeur de simuler l’interaction entre un utilisateur et son navigateur, et de vérifier le comportement des éléments d’interface.
• Compatible avec plusieurs navigateurs Web/mobiles et avec plusieurs langages de script.
• Communauté riche et dynamique

Les inconvénients de Selenium

• Selenium consomme beaucoup de ressources, puisqu’il lance une instance de navigation par utilisateur. 
• Peu adapté aux tests de charge puisque la consommation en ressources augmente drastiquement les coûts de mise à l’échelle. 
• Pas de compatibilité DevOps.  
• L’interface graphique n’est pas intuitive pour les développeurs. 
• Doit être couplé à JMeter, ce que nous cherchions justement à éviter. 

À la lumière de ces inconvénients, nous avons fait marche arrière et décidé de ne pas utiliser de navigateur sans tête.

Gatling

Gatling est l’une des options les plus prisées pour les tests de charge, et ce, à juste titre. Gatling est basé sur Scala, un choix curieux mais pas rédhibitoire. La prise en main est d’ailleurs facile, surtout quand on s’y connaît un peu en Java.  

• Code source libre 
• Cadre de tests basé sur le code 
• Orienté DevOps 
• Fonctionne comme une application Java 

Les avantages de Gatling

• Excellente capacité de gestion des connexions.
• Basé sur Akka et utilise un traitement asynchrone. Réduit la perte de performance causée par l’afflux d’utilisateurs sur un seul fil d’exécution.
• Exécutable depuis une interface en ligne de commande (CLI).
• Élimine la nécessité d’utiliser une interface graphique pour la création et l’exécution des tests.
• N’étant pas un navigateur sans tête, il consomme moins de ressources et facilite l’augmentation du volume d’utilisateurs.

Les inconvénients de Gatling

• La CLI manque de précision dans les informations fournies en temps réel.
• Le suivi graphique en temps réel nécessite l’intégration avec Taurus, une autre application.
• Bien que supérieure à celle de JMeter, sa performance reste moyenne comparée à d’autres options.
• En tant qu’application Java, il présente les mêmes difficultés de configuration que JMeter.

Locust

Le potentiel de Locust était évident d’emblée, Python se prêtant mieux à l’élaboration de plans de tests. La CLI offre un aperçu clair et simple des opérations en cours avec un rapport d’erreurs intégré.

• Bibliothèque Python légère
• Compatible DevOps
• Fonctionne sur la CLI
• Convivial pour les développeurs
• Tests d’échelle ajustables

Les avantages de Locust

• Les tests de charge distribués peuvent être étendus à un grand nombre d’utilisateurs. 
• Python est plus simple et rapide à configurer sur de nouvelles machines. 
• Interface web permettant une gestion flexible des tests.
• Visualisation des progrès en temps réel et décomposition des données par point de terminaison.
• Facilite l’utilisation des processeurs multicœurs pour intensifier les tests avec un grand nombre d’utilisateurs.
• N’est pas un navigateur sans tête.

Les inconvénients de Locust

• La version de base n’offre que le minimum syndical.
• La nature de Python fait que l’exécution du code ralentit pour chaque nouvel utilisateur simulé.
• Aucune fonctionnalité intégrée pour les assertions.

Locust : la solution idéale pour les tests de charge 

En fin de compte, Locust répondait le mieux à nos besoins. La facilité d’installation et d’utilisation de Python a été déterminante, la mise en œuvre étant rapide sur tout nouvel équipement. Il nous permet également de tirer parti d’une bibliothèque étendue pour adapter les tests. On y trouve d’ailleurs l’analyseur HTML très populaire et puissant BeautifulSoup, qui surpasse ses concurrents offerts par d’autres solutions de tests de charge.  

Les capacités asynchrones et le traitement multicœur de Locust sont d’autres atouts majeurs. J’ai pu simuler un volume élevé d’utilisateurs directement sur mon poste, sans déploiement sur des infrastructures plus puissantes comme AWS. À l’avenir, nous pourrons tirer parti du système de tests distribués de Locust pour une simulation à plus grande échelle. Cette fonctionnalité permet un déploiement sur plusieurs machines interagissant entre elles grâce à un système de messagerie.  

Même si je privilégie habituellement la CLI, l’interface web est également très utile pour surveiller un grand nombre de résultats sur un graphique actualisé en temps réel.