Chaque système fonctionne bien avec un seul utilisateur. Le problème commence par mille à la fois.
La plupart des équipes découvrent les limites de leur propre système de la pire des manières : en production, pendant les pics de production, sous l'œil du client. La campagne explose, l’article devient viral, l’échéance fiscale arrive, et ce qui semblait robuste s’effondre car personne n’a jamais mesuré combien cela pourrait durer.
Des tests de charge existent pour inverser cet ordre. Au lieu que l'utilisateur trouve la limite par accident, vous la trouvez volontairement, dans un environnement contrôlé, avant que cela ne fasse mal.
Qu'est-ce qu'un test de charge ?
Les tests de charge soumettent le système à un volume croissant de requêtes ou d'utilisateurs simultanés pour mesurer son comportement face à la demande. La question à laquelle il répond n’est pas « est-ce que ça marche ? », mais plutôt « est-ce que ça marche avec combien ? ».
Remarquez la différence. Un test fonctionnel vérifie que la fonctionnalité est correcte. Un test de charge vérifie qu'il reste correct et rapide lorsque plusieurs personnes l'utilisent en même temps. Ce sont des questions différentes, et la seconde n’apparaît qu’à l’échelle.
Vous simulez un nombre réaliste d'utilisateurs effectuant des actions réelles : connexion, recherche, paiement et observez le temps de réponse, le taux d'erreur et l'utilisation des ressources à mesure que la charge augmente. Le résultat est un portrait de la façon dont le système se dégrade.
La différence entre charge, stress et performance
Il vaut la peine de séparer les termes qui sont souvent confondus, car chacun répond à une question différente.
Les tests de charge mesurent le comportement face à une demande attendue et croissante, le nombre d'utilisateurs simultanés pris en charge par le système avec une qualité acceptable. Les tests de résistance vont volontairement par-dessus bord pour voir comment le système tombe en panne et se rétablit. Les tests de performances, au sens large, mesurent les temps de réponse et l’efficacité, souvent sous une certaine charge.
Cargo répond "peut-il tenir le coup comme prévu ?" Le stress répond « que se passe-t-il dans les cas extrêmes ? ». Les garder séparés dans votre tête évite de tirer de fausses conclusions d’un mauvais test.
Pourquoi il s'agit d'une décision commerciale, pas seulement technique
Il est tentant de considérer le fret comme un détail technique. C'est une erreur. La limite de capacité de votre système est la limite du nombre de clients que vous pouvez servir en même temps, et c'est une pure affaire.
Imaginez un service public de planification qui ouvre des postes vacants un jour précis. L’ensemble de la population éligible arrive dans le même créneau horaire. Si personne n’a testé la charge, le système plante au moment le plus important et la panne fait la une des journaux. Le coût n’est pas technique ; est institutionnellement fiable.
Il en va de même pour une startup préparant un lancement. Investir dans les médias pour provoquer un pic de trafic et maintenir le site Web hors ligne au moment du pic brûle deux fois de l'argent : les médias et la réputation.
Que mesurer et ce que cachent les métriques
Les mesures évidentes sont le temps de réponse et le taux d’erreur. Ils sont importants, mais ils ne racontent qu’une partie de l’histoire.
La météo moyenne est trompeuse. Une bonne moyenne peut cacher une fraction d’utilisateurs ayant une expérience épouvantable. C'est pourquoi je regarde les centiles, c'est-à-dire la période pendant laquelle les 5 % ou 1 % ont vécu la pire expérience, plutôt que les moyennes. C'est là que réside la vraie frustration.
Examinez également les ressources derrière : utilisation du processeur, mémoire, connexions bancaires, file d’attente des requêtes. Souvent, le goulot d'étranglement ne vient pas du serveur d'applications, mais de la base de données ou d'un pool de connexions de mauvaise taille. Le test de charge montre non seulement qu’il s’est dégradé ; bien instrumenté, montre où.
Les erreurs les plus courantes
La première erreur est de tester dans un environnement qui ne ressemble pas à de la production. Exécuter des charges sur une petite machine ou avec une banque vide génère des nombres magnifiques et inutiles. L'environnement de test doit être représentatif et les données doivent être similaires en volume à la réalité.
La seconde consiste à simuler des utilisateurs irréels. Un millier de requêtes identiques sur le même point de terminaison ne reflètent pas le comportement humain. Les vrais utilisateurs parcourent, réfléchissent, répètent des actions, abandonnent. Un scénario de charge utile reproduit ce modèle, et non un robot uniforme.
La troisième, et la plus courante, consiste à tester une fois, avant le lancement, et plus jamais. La capacité n’est pas statique. Chaque nouvelle fonctionnalité, chaque nouvelle requête auprès de la banque, peut modifier la limite. Les tests de charge non récurrents ont une courte validité.
Quand commencer à s'inquiéter
Tous les systèmes n’ont pas besoin de tests de charge dès le premier jour. Un produit interne utilisé par dix personnes ne justifie pas l’effort. La bonne question concerne l’exposition aux pics.
Si votre système connaît des moments prévisibles de demande concentrée, de campagnes, de délais, de lancements, de saisonnalité ou de croissance rapide de la base, les tests de charge ne sont plus facultatifs. Et le meilleur moment pour effectuer la première mesure est avant le premier pic important, pas après.
Le changement de mentalité que je préconise est simple : la capacité est une exigence, pas une surprise. Connaître le plafond de votre système est tout aussi important que de savoir s'il tient ses promesses. On vous dit que ça marche ; l’autre vous indique combien de temps il continuera à fonctionner lorsque le succès arrivera.
Si votre organisation est confrontée à un événement de pointe à l'horizon et que personne ne sait avec certitude si le système peut le gérer, c'est le type de risque qui mérite d'être pris en compte à l'avance et non pendant. J'ai d'autres textes sur le blog sur les performances, l'évolutivité et la fiabilité qui parlent de celui-ci.