Qu'est-ce que le capacity testing ?

Qu'est-ce que le capacity testing ?

Le capacity testing mesure la charge maximale soutenable qu'un système peut gérer tout en respectant ses service-level objectives (SLOs). La sortie est un nombre propre : "ce système gère X utilisateurs concurrents / Y requêtes par seconde à p95 latency sous Z." Ce nombre est la base pour le sizing infrastructure, les engagements contractuels et les revendications de capacité côté client.

Capacity testing vs breakpoint testing

Les deux rampent la charge au-delà du peak attendu. La différence est le critère d'arrêt :

• Le capacity testing s'arrête quand les SLOs sont violés pour la première fois (p95 dépasse votre seuil, error rate excède 0,5%, throughput cesse de scaler linéairement). La sortie est la charge la plus haute qui a encore respecté les SLOs.
• Le breakpoint testing continue au-delà de la violation SLO pour trouver le point de panne dur : où le système crashe, plante totalement ou cesse d'accepter les requêtes. La sortie est le plafond absolu, souvent bien au-delà de la performance acceptable.

Capacity = max avec SLO compliance. Breakpoint = max avant l'échec total. L'écart entre les deux est votre marge de sécurité.

Quand exécuter un capacity test

• Sizing infrastructure. Connaître la capacité d'un node vous dit exactement combien de nodes vous avez besoin pour le trafic cible plus marge.
• Négociation de contrat. Enterprise sales demande "est-ce que ça peut gérer 50 000 utilisateurs ?" — le capacity testing donne une réponse honnête.
• Engagement SLA. Promettre 99,9% de disponibilité à une charge spécifique exige une preuve que la charge est dans la capacité.
• Validation pre-launch. Marketing prévoit 5 000 utilisateurs concurrents au lancement. Le capacity testing confirme que le système les gère avec marge, ou signale que 5 000 est au-delà de la capacité et qu'il faut scaler.
• Configuration autoscaling. Capacité par pod divisée par l'utilisation cible vous donne le trigger de scale-out.

Métriques clés de capacity test

1. Nombre de VUs ou RPS maximal soutenable. La sortie principale. Le niveau de charge auquel les SLOs ont été respectés en dernier.
2. Marge au breakpoint. Ratio capacity / breakpoint. Une capacité à 80% du breakpoint est saine ; capacité à 99% du breakpoint est fragile.
3. Utilisation de ressources à capacité. CPU, mémoire, connexions DB, thread pool au nombre de capacité. Vous dit quelle dimension scaler.
4. Temps à capacité. Le système tient-il la charge de capacité pour la durée SLO complète (15 min, 1 heure, 24 heures) ? Certains systèmes atteignent un VU count élevé brièvement mais se dégradent dans le temps sous charge soutenue.

Comment exécuter un capacity test

Mêmes scripts que load testing, avec un step-ramp qui pause à chaque niveau assez longtemps pour confirmer la SLO compliance. Dans JMeter, utilisez le Stepping Thread Group pour tenir à chaque niveau VU pendant 5-15 minutes avant de monter. Dans k6, configurez un scénario ramping-vus multi-étape avec des holds soutenus à chaque step.

Définissez votre seuil SLO d'abord (ex. "p95 latency sous 800 ms, error rate sous 0,5%"). La capacité est le step le plus haut auquel le SLO a tenu pour la durée hold complète. Baissez d'un step pour une marge de sécurité.

Exécutez depuis LoadFocus pour capacity testing distribué où les load generators dans plusieurs régions testent la capacité géo-distribuée du système, pas seulement single-region.

Pour capacity testing qui informe des engagements de capacité au niveau du board, LoadFocus propose des load testing services où des ingénieurs exécutent le test, documentent la capacité avec le contexte infrastructure et produisent un rapport adapté aux stakeholders.