JMeter
Introduction à JMeter
JMeter est un outil de test de charge mature et populaire, développé par la Fondation Apache. Initialement conçu pour tester des applications web, JMeter prend désormais en charge une large gamme de protocoles, y compris HTTP, FTP, SMTP, et plus encore. JMeter est souvent le choix privilégié pour les tests de charge et de stress en raison de sa robustesse et de ses fonctionnalités avancées.
Pourquoi choisir JMeter ?
JMeter se distingue par sa capacité à tester différents types d’applications grâce à sa prise en charge de multiples protocoles, en plus d’être extensible avec de nombreux plugins. C’est un outil bien établi et éprouvé, ce qui signifie qu’il est bien documenté et dispose d’une grande communauté. Il propose également une interface graphique pour la création de tests, ce qui peut être un avantage pour les équipes qui préfèrent une approche visuelle.
Fonctionnalités Clés de JMeter
- Support multi-protocole : JMeter permet de tester non seulement des applications web, mais aussi des applications FTP, des serveurs de messagerie, des bases de données, etc., ce qui le rend extrêmement polyvalent.
- Interface graphique complète : JMeter offre une interface graphique qui simplifie la création de tests pour les personnes non-développeuse. Elle permet de visualiser chaque étape d’un test, de configurer facilement les éléments de test et de surveiller les résultats.
- Fonctionnalités de Reporting : JMeter génère des rapports détaillés et permet de visualiser les résultats sous forme de graphiques, ce qui aide à analyser les performances et identifier les goulots d’étranglement.
- Extensions via des plugins : La communauté de JMeter propose une large gamme de plugins pour étendre ses capacités et l’adapter aux besoins spécifiques des tests.
Cas d’utilisation de JMeter en entreprise
- Tests de charge d’applications web et d’APIs : JMeter est idéal pour tester les performances d’applications web et des APIs REST ou SOAP.
- Validation de services diversifiés : Avec sa capacité multi-protocole, JMeter est particulièrement adapté aux environnements complexes qui nécessitent des tests pour différents services comme les bases de données ou les serveurs de fichiers.
- Tests pour des environnements d’intégration continue : Grâce à ses fonctionnalités avancées de reporting et de ligne de commande, JMeter s’intègre bien dans les pipelines CI/CD.
Limites de JMeter
La nature basée sur Java de JMeter le rend parfois gourmand en ressources, en particulier pour des charges importantes. Bien que son interface graphique soit un avantage pour certains, elle peut être lente lors des gros tests et moins flexible que les solutions basées sur le code.
Installation de JMeter
Assurez-vous que Jmeter est installé sur votre machine. Vous pouvez l’installer en téléchargeant le binaire sur :
https://jmeter.apache.org/download_jmeter.cgi
Puis exécuter le fichier jmeter.bat qui se trouve dans le dossier bin. L’interface GUI apparaitra quelques secondes après.
Création de test de base
- Créez un nouveau plan de test :
- Cliquez sur « File > New ».
- Renommez le plan de test en cliquant avec le bouton droit sur « Test Plan » et en sélectionnant « Rename ».
- Ajoutez un groupe d’utilisateurs virtuels :
- Cliquez avec le bouton droit sur le plan de test, puis « Add > Threads (Users) > Thread Group ».
- Configurez le nombre de personne, la durée du test et le ramp-up time selon vos besoins.
Le mode GUI ne doit être utilisé que pour créer le script de test, le mode CLI (NON GUI) doit être utilisé pour les tests de charge
Configurer la requête HTTP
- Ajoutez un requêteur HTTP :
- Cliquez avec le bouton droit sur le groupe d’utilisateurs, puis « Add > Sampler > HTTP Request ».
- Configurez les détails de la requête :
- Serveur : jsonplaceholder.typicode.com
- Méthode : GET (ou POST si vous voulez tester des écritures).
- Chemin : /posts (ou tout autre endpoint de l’API).
- Ajoutez des paramètres si nécessaire (par exemple, pour filtrer les posts via userId).
Ajout d’un listener pour les résultats
Ajoutez un écouteur pour voir les résultats des tests :
-
- Cliquez avec le bouton droit sur le groupe d’utilisateurs, puis « Add > Listener > View Results Tree ».
- Vous pouvez également ajouter d’autres écouteurs, comme « Summary Report » ou « Aggregate Report ».
Lancer le test
- Lancez le test en cliquant sur le bouton Run (flèche verte dans la barre d’outils).
- Sauvegardez votre test
- Observez les résultats dans les écouteurs configurés.
Analyse des résultats
- View Results Tree : Permet de vérifier les détails de chaque requête et réponse.
- Summary Report : Donne un aperçu des performances globales, notamment le temps moyen de réponse, le nombre d’échecs, etc.
Analyse des résultats
Détails techniques observés :
- Load time (153 ms) : C’est le temps total pris pour exécuter la requête et recevoir une réponse complète. Ce temps semble raisonnable pour une requête simple sur une API REST.
- Connect Time (89 ms) : Le temps pris pour établir la connexion avec le serveur. Un temps inférieur à 100 ms est généralement bon, surtout si le serveur est distant.
- Latency (134 ms) : Le temps entre l’envoi de la requête et le début de la réception des données. Ce temps est légèrement plus élevé que le connect time, ce qui est logique.
- Body size in bytes (27533) : La taille du corps de la réponse en octets. Cela indique que vous avez reçu une réponse conséquente, probablement un tableau JSON contenant plusieurs objets.
- Response Code (200) : Le code HTTP 200 signifie que la requête a été exécutée avec succès.
- Content-Type (application/json; charset=utf-8) : La réponse est au format JSON avec un encodage UTF-8. Cela confirme que la réponse est bien formatée pour des données structurées.
Analyse des performances :
- Performance acceptable : Les temps (load time, connect time et latency) sont tous dans des limites normales pour un test d’une API publique comme JSONPlaceholder.
- Réponse correcte : Le code HTTP 200 et le format JSON confirment que l’API fonctionne correctement et renvoie les données attendues.
- Taille de la réponse (Body size) : La taille de 27 533 octets montre que la réponse contient probablement de nombreuses données (un tableau de posts en JSON, typique pour /posts). Vous pouvez voir les données dans l’onglet response Data :
Résumé des résultats :
- # Samples : 1
- Cela signifie que vous avez exécuté une seule requête HTTP (un échantillon unique).
- Cela est cohérent pour un test de base ou un test initial.
- Average, Min, Max : 258 ms
- Ces trois valeurs étant identiques (258 ms) indiquent que vous n’avez qu’une seule requête dans ce test, donc pas de variation dans les temps de réponse.
- Temps de réponse moyen (258 ms) : Cela est un temps raisonnable pour une API publique.
- Error % : 0.00%
- Aucune erreur n’a été rencontrée lors de l’exécution du test. C’est une bonne indication que la configuration est correcte et que le serveur a bien répondu.
- Throughput : 3.9/sec
- Cette métrique indique que votre système pourrait gérer environ 3,9 requêtes par seconde dans les conditions actuelles.
- Avec une seule requête exécutée, ce chiffre reflète le temps entre la requête et la réponse.
- Received KB/sec : 109.21 KB/sec
- La vitesse à laquelle les données de réponse ont été reçues.
- Cela dépend de la taille de la réponse (27 533 bytes pour une requête), et c’est cohérent pour une réponse JSON volumineuse.
- Sent KB/sec : 0.51 KB/sec
- La vitesse des données envoyées. Cela est faible car la requête GET n’inclut que des headers et très peu de données.
- Avg. Bytes : 28 853.0
- Taille moyenne de la réponse (en bytes) pour chaque requête. Cela correspond bien à la taille de la réponse JSON de l’API /posts.
Vous pouvez également ajouter d’autres listeners : aggregate report ou graph results pour visualiser les performances globales et l’évolution du temps de réponse.