Qu'est-ce que le capacity testing ?

Qu'est-ce que le capacity testing ?

Le capacity testing (test de capacité) détermine la charge la plus élevée qu'un système peut supporter tout en respectant ses objectifs de performance, comme un temps de réponse p95 ou un taux d'erreurs maximal. Vous augmentez la charge par paliers et vous vous arrêtez au dernier palier où tous les objectifs étaient tenus. Le résultat est un chiffre concret, par exemple des utilisateurs simultanés ou des requêtes par seconde, qui sert à dimensionner les serveurs et à planifier la croissance.

Comment se déroule un test de capacité

1. Fixez d'abord les objectifs. Par exemple : p95 sous 800 ms et taux d'erreurs sous 0,5 %. Ce sont vos objectifs de niveau de service (SLO).
2. Montez par paliers. Partez en dessous du trafic attendu et ajoutez de la charge par pas égaux, en tenant chaque palier assez longtemps pour lire des valeurs stables (5 à 15 minutes est courant).
3. Vérifiez tous les objectifs à chaque palier. Le premier palier où l'un d'eux n'est plus tenu termine le test.
4. Lisez le résultat. La capacité est le dernier palier où tout était tenu. Prévoyez de fonctionner en dessous, avec une marge de sécurité.

Exemple : une API de paiement tient ses objectifs à 300, 400 et 500 utilisateurs virtuels, puis le p95 dépasse la limite à 600. La capacité est de 500 utilisateurs. Si vous attendez 450 au pic, la marge est mince : montez en charge avant le lancement, pas après.

Capacity testing et breakpoint testing

Les deux poussent la charge au-delà du pic attendu. La différence tient au critère d'arrêt :

• Le capacity testing s'arrête dès que les objectifs sont violés pour la première fois. Le résultat est la charge la plus haute qui les respectait encore.
• Le breakpoint testing continue jusqu'à la défaillance franche du système. Le résultat est le plafond absolu, souvent bien au-delà d'une performance acceptable.

L'écart entre les deux est votre marge de sécurité. Pour une vue plus large, voir les tests de scalabilité, qui étudient comment la capacité évolue quand on ajoute des ressources, et la comparaison du blog load testing vs stress testing.

Quand lancer un test de capacité

• Dimensionner l'infrastructure. La capacité d'un nœud indique combien de nœuds il faut pour le trafic cible plus la marge.
• Avant un lancement ou une campagne. Vérifiez que le trafic prévu tient dans la capacité tant qu'il est encore temps d'agir.
• Règles d'autoscaling. La capacité par instance divisée par le taux d'utilisation visé donne un déclencheur de montée en charge raisonnable.
• Après un changement important. Une nouvelle base de données, un nouveau framework ou un cache peuvent déplacer la capacité dans les deux sens.

Ce qu'il faut relever à la capacité

• Maximum d'utilisateurs ou de requêtes par seconde soutenables. Le résultat principal.
• Marge avant le breakpoint. Une capacité à 80 % du breakpoint est confortable ; à 99 %, elle est fragile.
• Utilisation des ressources à la capacité. CPU, mémoire, connexions à la base et pools de threads montrent quoi faire évoluer en premier.
• Durée à la capacité. Certains systèmes passent un palier court puis se dégradent sous charge soutenue. Tenez le dernier palier aussi longtemps que votre SLO l'exige et utilisez un soak test plus long pour les fuites lentes.

Erreurs fréquentes

• Ne pas définir d'objectifs : la "capacité" devient une impression, pas un chiffre.
• Monter trop vite. Les files d'attente et les caches ont besoin de temps, et des paliers courts surestiment la capacité.
• Tester un seul endpoint alors que le trafic réel est un mélange. Utilisez un scénario réaliste.
• Lire des moyennes plutôt que des percentiles. Voir la latence pour comprendre pourquoi la moyenne masque les requêtes lentes.
• Tester un environnement plus petit que la production et extrapoler à l'estime.

Le faire avec LoadFocus

Le capacity testing utilise les mêmes scripts que les tests de charge, avec une rampe par paliers. Les tests JMeter et k6 peuvent tous deux être lancés depuis le cloud, et les tests de charge LoadFocus partent de 25 régions cloud : vous mesurez la capacité telle que la vivent des utilisateurs de plusieurs régions. Vous pouvez définir des seuils sur le temps de réponse p95 et p99, le taux d'erreurs maximal et le débit minimal ; chaque exécution reçoit un verdict réussi ou échoué, qui peut bloquer un déploiement depuis la CI. Le plan Free est limité à 10 utilisateurs virtuels ; les plans payants vont jusqu'à 20 000 utilisateurs simultanés par test.

Questions fréquentes

Quelle différence entre capacity testing et load testing ?

Le load testing vérifie le comportement à une charge attendue. Le capacity testing continue d'augmenter la charge pour trouver le maximum que le système supporte dans ses objectifs.

En quoi la capacité diffère-t-elle du breakpoint ?

La capacité est le dernier niveau de charge qui respectait encore vos objectifs. Le breakpoint est le point où le système défaille vraiment. La capacité est toujours inférieure, et l'écart est votre marge de sécurité.

Combien de temps tenir chaque palier ?

Assez longtemps pour que les temps de réponse se stabilisent, généralement 5 à 15 minutes. Les systèmes avec caches, files d'attente ou pools de connexions demandent des paliers plus longs.

Quelles métriques définissent la capacité ?

Les percentiles du temps de réponse (p95 ou p99), le taux d'erreurs et le débit. La capacité est la charge la plus haute où les trois restent dans les objectifs fixés.

À quelle fréquence refaire un test de capacité ?

Après des changements importants de code, d'infrastructure ou de volume de données, et avant les pics de trafic prévus. Une exécution planifiée détecte les dégradations lentes entre ces moments.