← évolutif
420-5A4-MT · Module 2 · Semaine 7 · Laboratoire

Le test de charge
avec JMeter

Mesurer scientifiquement ce que le serveur encaisse : construire un test, l'exécuter, interpréter les résultats - puis brutaliser les serveurs pour trouver la limite.

1 · Construire un test de base

Fenêtre de démarrage de JMeter avec un Test Plan
JMeter au démarrage : tout part du Test Plan.

Ajouter un Thread Group (les usagers simulés)

Clic droit sur Test Plan → Add → Threads (Users) → Thread Group.

Réglages du Thread Group dans JMeter
Le Thread Group : la taille de la foule.

Ajouter HTTP Request Defaults

Sélectionner le Thread Group, clic droit → Add → Config Element → HTTP Request Defaults. Dans la section Web Server, remplir Server Name or IP avec l'adresse du serveur web à tester.

HTTP Request Defaults dans JMeter
La cible du test : votre serveur.

Ajouter un HTTP Request Sampler

Sélectionner le Thread Group, clic droit → Add → Sampler → HTTP Request. Dans la section HTTP Request, mettre Path à / : chaque usager simulé demandera la page d'accueil.

HTTP Request Sampler dans JMeter
Ce que chaque usager demande.

Ajouter la vue View Results in Table

Sélectionner le Thread Group, clic droit → Add → Listener → View Results in Table.

Listener View Results in Table dans JMeter
La table où les résultats vont apparaître.
Contexte Client Cornucopia

Cornucopia · Application Pratique sur le Terrain

Ce laboratoire technique s'inscrit directement dans l'infrastructure de la ferme maraîchère de Flora et Hazel pour garantir la réactivité et la stabilité de leurs services bio en ligne.
Cas d'Usage Concret

Appliquer les configurations optimisées pour soutenir les pics de consultation des abonnés de la ferme.

2 · Exécuter un test

Table de résultats JMeter remplie
Les colonnes qui comptent : Status, Latency, Sample Time.

3 · Interpréter les résultats

La colonne Status n'est pas entièrement verte ?

C'est l'indicateur minimum de réussite : verte partout, le serveur a répondu à tous les appels sans code d'erreur. Sinon : baisser le nombre d'usagers simulés, ou augmenter le Ramp-Up Period, et refaire le test.

La colonne Latency dépasse le seuil souhaité ?

Latency : les millisecondes entre l'envoi de la requête et la première réponse - le temps que le site prend pour COMMENCER à apparaître chez l'usager. Trop haut : baisser la charge et refaire le test.

Le sommaire Average est trop élevé ?

Average : la moyenne des temps de réponse complets - apparaître ET finir de charger. Trop haut : baisser la charge et refaire le test.

Le temps idle du processeur est très bas ?

Avec une console SSH, se connecter sur chaque serveur et exécuter :

$ top
Sortie top avec processeur au repos, idle à 99 pour cent
Au repos : us très bas, id à 99 % et plus.

Relancer le test JMeter et revenir à la session SSH : l'utilisation des ressources grimpe.

Sortie top avec processeur saturé, idle à 0 pour cent
Sous charge : 94 % usager, 4,7 % système, 0 % idle - la mémoire tient, c'est le processeur qui manque !
C'est exactement la mesure qui prouve la séparation : avant/après, quel serveur sature en premier - le web ou la base de données ?

4 · Brutaliser les serveurs

Quand le but n'est pas d'estimer les performances mais d'éprouver l'endurance, il faut sortir des sentiers battus : augmenter les usagers simulés ET réduire le Ramp-Up.

Si la colonne Status n'est pas entièrement verte... c'est normal ! Les lectures les plus intéressantes viennent de la commande top : l'exercice montre quelles ressources lâchent en premier.

Références : DigitalOcean - How To Use Apache JMeter To Perform Load Testing · htop explained (document partagé) · Document du cours recréé en HTML pour la semaine 7 · Voir aussi l'installation en deux serveurs.