On n'apprend pas la capacité d'un service le jour de la campagne. Un test de charge est un entraînement : on monte progressivement, on observe où le souffle manque et on règle l'allure. Voici comment en tirer des chiffres que l'on peut croire.
Définir ce qu'on veut apprendre
Avant de lancer l'outil, posez la question : tient-on dix fois le trafic habituel, combien d'utilisateurs avant que le temps de réponse dépasse un seuil, que se passe-t-il quand une dépendance ralentit ? Un test sans question précise produit des graphiques et peu de décisions.
Reproduire un trafic réaliste
Un test qui rappelle toujours la même page flatte les caches et ment sur la capacité. Mélangez les parcours, variez les données et incluez les requêtes lourdes. Les journaux de production donnent la proportion réelle entre pages, API et fichiers statiques.
Lire latence, débit et simultanéité ensemble
Ces trois grandeurs sont liées : la simultanéité est le débit multiplié par le temps de service. Si la latence double, la capacité en requêtes par seconde est divisée par deux avec le même nombre de workers. Le calcul de capacité rend ce lien explicite.
Chercher le genou de la courbe
Montez la charge par paliers et notez le point où le temps de réponse se met à croître brutalement. C'est la zone à éviter en exploitation. Visez une utilisation nettement inférieure, pour absorber les irrégularités du trafic.
Tester aussi la durée
Un service peut tenir une heure et fuir de la mémoire sur une journée. Un test d'endurance de plusieurs heures révèle les fuites, les journaux qui grossissent et les connexions qui s'accumulent, notamment l'épuisement des ports locaux.
Partager les résultats et décider
Un test de charge n'a de valeur que s'il débouche sur une décision : agrandir, optimiser, limiter le trafic ou accepter le risque. Rédigez une courte synthèse avec la question de départ, la méthode, le point de saturation observé et la marge retenue. Joignez les réglages utilisés pour pouvoir refaire le test après un changement. Conservez le rapport avec la date et la version testée : il servira de référence lors du prochain dimensionnement et évitera de repartir de zéro.
Checklist avant de commencer
- Question précise posée avant le test
- Trafic de test construit à partir des journaux réels
- Charge montée par paliers avec mesure à chaque palier
- Latence, erreurs et ressources suivies en même temps
- Test d'endurance de plusieurs heures réalisé
- Environnement de test proche de la production
Questions fréquentes
Peut-on tester en production ?
Avec précaution, hors des pics, en prévenant les équipes et en gardant un moyen d'arrêter immédiatement. Sinon, utilisez un environnement aussi proche que possible.
Les résultats sont-ils transposables ?
Seulement si l'environnement de test ressemble à la production. Sinon, utilisez-les pour comparer des réglages, pas pour promettre une capacité.
À quelle fréquence refaire un test ?
À chaque changement important d'architecture ou de version, et avant une période de trafic attendu plus élevé. Un test ancien ne décrit plus un système qui a évolué.
Ce guide présente des principes généraux : il ne note ni ne recommande aucun site de l'annuaire ni aucun prestataire. Les règles juridiques citées sont rappelées de manière simplifiée : vérifiez-les auprès des sources officielles.
Besoin de matériel ou de fournitures ? L'annuaire classe 26 sites dans la rubrique Baie sportive.
Ouvrir la baieCalculateurs utiles
- 15Latence en ms et requêtes par secondeCapacité d'un service à partir de sa latence et de ses workers
- 09Débit pour N utilisateurs simultanésRequêtes par seconde et débit sortant d'une audience simultanée
- 19Connexions simultanées et portsOccupation de la plage de ports éphémères d'un client