Locust

Introduction à Locust

Locust est un outil open-source de test de charge conçu pour être utilisé de manière très flexible et extensible. Contrairement à de nombreux outils classiques de test de charge, Locust permet d’écrire des scénarios de test en Python, offrant ainsi aux équipes une souplesse dans la création de comportements réalistes et complexes.

Pourquoi choisir Locust ?

La force principale de Locust réside dans sa capacité à simuler des personnes réalistes. Plutôt que de simplement envoyer des requêtes, Locust permet de reproduire des comportements détaillés, ce qui est particulièrement utile pour tester des systèmes ayant des flux spécifiques ou des applications web avec des interactions multiples. De plus, son architecture distribuée permet d’évoluer pour tester des charges très importantes.

Fonctionnalités Clés de Locust

Locust utilise Python pour définir les scénarios, rendant les tests intuitifs et permettant aux testeurs de tirer parti des bibliothèques Python. La syntaxe est facile à apprendre et permet une grande flexibilité dans les comportements simulés.
Locust dispose d’une interface web intégrée permettant de surveiller les tests en temps réel, d’ajuster la charge ou d’arrêter le test à tout moment.
En configurant plusieurs instances de Locust, il est possible de simuler des centaines de milliers de personnes simultanées, ce qui est essentiel pour tester des applications très sollicitées.
Locust permet d’imiter des comportements humains, avec des pauses entre les actions, des enchaînements logiques et des variables de temps d’attente.

Cas d’utilisation de Locust en entreprise

Tests de charge pour des applications à flux complexes : Locust est particulièrement adapté aux applications où les personnes suivent des parcours spécifiques, comme des achats ou des formulaires en ligne.
Simulation de grandes charges distribuées : Avec son architecture distribuée, Locust est idéal pour des environnements où des pics de charge significatifs sont attendus, par exemple lors de campagnes marketing.
Locust est couramment employé pour les API REST grâce à la flexibilité de son scripting Python

Limites de Locust : bien que Locust offre une grande flexibilité, il requiert des connaissance s en Python, ce qui peut être une barrière pour les équipes sans développeurs Python. En outre, Locust peut être gourmand en ressources lorsque les tests nécessitent de nombreuses personnes simultanées, ce qui peut demander une infrastructure importante pour les gros tests.

Résumé des points clefs

Les avantages de Locust

Simplicité : Écrire des tests de charge avec Python permet une grande flexibilité. Locust est particulièrement adapté pour simuler des comportements complexes, tout en restant accessible aux développeurs et testeurs.
Extensibilité : Locust peut être déployé sur plusieurs machines pour simuler des milliers, voire des millions de personnes simultanément, rendant possible des tests massifs.
Interface web conviviale : Locust fournit une interface web simple pour lancer, surveiller et ajuster vos tests en temps réel.
Comportement personnalisé : Grâce à la programmation des tests en Python, vous pouvez simuler des scénarios réalistes et variés.

Les inconvénients de Locust

Dépendance au langage Python : Bien que Python soit largement utilisé, cela peut être un obstacle pour les équipes qui ne sont pas familières avec ce langage. Si votre équipe n’a pas de compétences en Python, cela peut rendre l’écriture des scénarios de test plus difficile.
Complexité de mise en place des tests distribués : Bien que Locust supporte les tests distribués (lorsque vous voulez simuler des milliers de personnes à partir de plusieurs machines), la mise en place peut parfois être complexe. Il faut gérer manuellement les workers (machines) et assurer la bonne synchronisation entre elles, ce qui peut devenir un défi pour les tests à très grande échelle.
Rapports de résultats simplifiés : Par défaut, Locust fournit des rapports assez basiques avec le nombre de requêtes, le taux d’échec, et le temps de réponse moyen. Contrairement à des outils comme JMeter, il manque certaines métriques avancées comme les percentiles des temps de réponse (bien qu’ils puissent être calculés manuellement) ou des graphiques détaillés intégrés. Pour des rapports plus complexes, il faut souvent exporter les données et les traiter avec des outils externes.
Pas d’interface graphique pour la création de scénarios : Locust repose entièrement sur l’écriture de code Python pour la configuration des tests. Contrairement à JMeter, qui propose une interface graphique (GUI) pour configurer les scénarios de test, Locust nécessite des compétences en programmation pour définir les interactions, ce qui peut être un frein pour certains testeurs moins techniques.
Support restreint pour les protocoles non-HTTP : Locust est principalement orienté vers les tests d’applications web et d’API REST (protocoles HTTP/HTTPS). Il n’est pas adapté à d’autres types de protocoles comme FTP, SMTP, ou encore des tests d’applications utilisant des protocoles plus spécifiques, contrairement à des outils comme JMeter ou LoadRunner.

Installation de locust

L’installation de Locust est rapide. Après avoir installé Python, il suffit de taper :

pip install locust

Création d’un test de base

Ensuite, créez un script de test Python qui décrit les actions que votre clientèle effectuera. Voici un exemple simple, nommé le fichier mon_fichier.py :

from locust import HttpUser, task, between

class JSONPlaceholderUser(HttpUser):
wait_time = between(1, 3)

@task(3)
def get_posts(self):
self.client.get(« /posts »)

@task(2)
def get_comments(self):
self.client.get(« /comments »)

@task(1)
def get_users(self):
self.client.get(« /users »)

Ce script simule des personnes qui visitent deux pages (/ et /about). wait_time est utilisé pour spécifier un temps d’attente aléatoire entre deux actions afin de mieux simuler un comportement humain.

Lancer le test

Pour démarrer le test, il suffit de lancer la commande suivante :

locust -f mon_script.py

Cela ouvrira une interface web à l’adresse http://localhost:8089. À partir de là, vous pouvez configurer le nombre de personne et leur fréquence d’arrivée pour commencer le test.

Ci-dessus : l’interface graphique de Locust. Vous y trouverez les options :

Nombre de personnes simulés (Number of users) : vous permet de spécifier combien de personnes simultanées seront simulés pendant le test.
Taux de montée en charge (Spawn rate) : Ici, vous définissez le nombre de personne par seconde qui seront ajoutés jusqu’à atteindre le nombre total de personnes. Cela permet de moduler la montée en charge plutôt que de lancer toutes les personnes en même temps.
Hôte (Host) : Cette option vous permet de définir l’URL de l’application cible.
Durée du test (Run time): Sous sous le bouton advanced options, vous pouvez définir une durée spécifique pendant laquelle Locust exécutera le test avant de s’arrêter automatiquement. C’est particulièrement pratique lorsque vous voulez simuler une charge sur une période précise sans avoir à surveiller manuellement l’interface pour arrêter le test.
Bouton de démarrage (Start) : Une fois les paramètres définis, cliquez sur « Start » pour lancer le test.

ANALYSE DE RESULTATS

Après avoir mis 10s en run time et cliquez sur start, vous aurez un résultat similaire à :

Le tableau montre deux endpoints testés :

1./comments : 3 requêtes
2./posts : 2 requêtes

Aucun échec n’a été enregistré (# Fails = 0), ce qui montre que les endpoints testés ont répondu correctement sous la charge appliquée. La stabilité du système est satisfaisante pour ce scénario.

Temps de réponse :
Temps médian

:/comments:48ms
/posts : 25,13 ms

Ces valeurs indiquent que 50 % des requêtes ont un temps de réponse égal ou inférieur à ces chiffres, montrant une bonne rapidité globale.

Temps moyen (Average) :

/comments:59,06ms
/posts : 100,71 ms

Ces valeurs légèrement supérieures aux médianes montrent une petite variabilité, en particulier pour
/posts.

95e et 99e percentiles :

/comments : 98 ms pour les deux percentiles, montrant une certaine constance.
/posts : 180 ms pour les deux percentiles, indiquantunedispersionplusimportante,avec desrequêtespluslentespourceendpoint.

Taille moyenne des réponses :
Les tailles des réponses diffèrent considérablement :

/comments : 157 745 octets (réponses
volumineuses).
/posts : 27 520 octets (taille beaucoup plus
réduite).

Les réponses volumineuses pour /comments peuvent avoir un impact plus important sur les temps de réponse et la bande passante.

Débit :
Le débit global est de 0,5 requêtes par seconde (RPS). Cela correspond à une charge légère, adaptée pour un test exploratoire ou initial.
Les endpoints ont un débit faible :

/comments : 0,33 requêtes/s
/posts : 0,17 requêtes/s

Max et min temps de réponse :
/comments :

Temps minimum : 32 ms
Temps maximum : 98 ms

Ces valeurs sont proches de la médiane et des percentiles, montrant une bonne stabilité pour ce endpoint.

/posts :

Temps minimum : 25 ms
Temps maximum : 176 ms

L’écart plus important pour /posts indique une légère variabilité, possiblement liée à des opérations backend plus complexes ou à des ressources réseau.

Graphiques

Dans l’interface graphique, vous avez 3 graphiques, dont voici les deux plus intéressants pour notre test :

Total Requests per Second (RPS) – Requêtes par seconde :

Le graphique du haut montre l’évolution du nombre de requêtes par seconde (RPS) au cours du test. Le graphique montre une montée progressive du RPS, qui atteint 1 requête par seconde à 15:23:24. Ce débit reste stable à son maximum avant de redescendre à 0,5 vers 15:23:28. Ce résultat montre que la charge de test appliquée est faible, avec une seule requête toutes les deux secondes en moyenne, ce qui est normal si le but est de tester des capacités basiques de réponse et de stabilité.
L’absence de failures/s (échecs par seconde), indiquée par la ligne rouge plate à zéro, est un signe positif : le système n’a rencontré aucune défaillance lors de l’exécution de ces requêtes. C’est un bon indicateur de stabilité sous cette charge spécifique.

Users :

Le graphique User permet évaluer la montée en charge, la stabilité et la résilience de l’application testée. En combinant l’analyse de ce graphique avec les métriques de performance (temps de réponse, taux d’erreur), vous pouvez déterminer les limites actuelles de son système et prioriser les optimisations à apporter pour améliorer la capacité de charge.

Response Times – Temps de réponse :

Le graphique du bas détaille les temps de réponse en millisecondes. Deux percentiles sont affichés :
- 50e percentile (jaune) : Indique le temps de réponse médian, soit 180 ms à 15:23:24, ce qui signifie que 50 % des requêtes ont un temps de réponse inférieur ou égal à cette valeur.
- 95e percentile (violet) : Le temps de réponse au 95e percentile est également de 180 ms, ce qui signifie que 95 % des requêtes ont été traitées en 180 ms ou moins.
Les 50e et 95e percentiles étant identiques, cela indique une faible variabilité dans les temps de réponse pour ce test. Cela suggère une stabilité dans le traitement des requêtes, avec peu ou pas de déviations majeures.

Interprétation :

Bien que les temps de réponse soient stables, le temps médian de 180 ms peut être considéré comme élevé pour certains types de requêtes GET. Ce résultat pourrait indiquer :

Une latence légèrement accrue due à des opérations backend.
Une saturation mineure des ressources pour ces requêtes spécifiques.

Utilisation avancée de Locust

Pour des scénarios plus complexes, Locust offre de nombreuses possibilités :

Tests distribués : Vous pouvez lancer plusieurs travailleurs (workers) sur différentes machines pour distribuer la charge.
Simuler différents types d’utilisateurs : Locust permet de créer plusieurs classes d’utilisateurs avec des comportements variés, afin de tester différents flux d’interaction dans votre application.
Intégration continue : Vous pouvez intégrer Locust dans vos pipelines de CI/CD pour effectuer régulièrement des tests de charge, garantissant que les performances restent optimales au fur et à mesure des modifications.

Test distribué avec Locust

Locust permet de réaliser des tests distribués grâce à son architecture évolutive. L’outil fonctionne en mode maître/esclave, où le maître coordonne les tests et les esclaves génèrent la charge.

Pour configurer un test distribué avec Locust, vous devez définir plusieurs instances de Locust (esclaves) qui communiqueront avec l’instance principale (maître). Chaque esclave peut être sur une machine distincte, ce qui permet de simuler un grand nombre de personne sans saturer une seule machine.
Par exemple, pour démarrer un test distribué :

locust -f locustfile.py –master

Et sur chaque machine esclave :

locust -f locustfile.py –worker –master-host=<IP_du_master>

Lors de la configuration de plusieurs machines, vérifiez que la montée en charge est bien répartie entre les personnes simulées par seconde. Une montée en charge trop rapide sur une seule machine peut entraîner des goulots d’étranglement.