Qu'est-ce que le breakpoint testing ?

Qu'est-ce que le breakpoint testing ?

Le breakpoint testing est un test de performance qui rampe la charge progressivement contre un système jusqu'à ce que quelque chose cède. Les response times grimpent au-dessus des SLOs, l'error rate monte, le throughput plateaue ou un processus crashe. L'objectif est d'identifier le plafond de capacité précis pour que la planification de capacité, les seuils d'autoscaling et les engagements SLO reposent sur de vraies données plutôt que sur des suppositions.

Breakpoint testing vs stress testing

Le stress testing pousse au-delà du peak attendu avec l'objectif de comprendre le failure mode et la récupération. Le breakpoint testing est plus étroit : identifier le point exact où le système casse. Stress c'est de l'exploration ; breakpoint c'est de la mesure.

Pour la charge maximale qui respecte encore les SLOs (le plafond de sécurité pratique plutôt que le point de cassure dur), voir capacity testing.

En pratique les deux tournent souvent ensemble. Un stress test produit un breakpoint comme sous-produit. Mais cadrer le test comme "breakpoint test" focalise le design sur la précision : steps de ramp propres, critères de cassure bien définis, changements à une seule variable entre runs.

Quand exécuter un breakpoint test

• Planification de capacité. Avant d'engager un budget infrastructure, sachez ce qu'un node / pod / container gère réellement à la frontière SLO.
• Engagement SLO. Avant de promettre 99,9% de disponibilité à X RPS, validez que le système gère X RPS de façon fiable.
• Réglage de seuil d'autoscaling. Si le breakpoint est à 80% CPU + 1500 RPS, scale-out à 70% CPU est bien calibré. Sans un breakpoint mesuré vous devinez.
• Évaluation de vendor. Comparaison de providers CDN, options DB ou types d'instance ? Breakpoint chacun et comparez les plafonds directement.
• Validation post-changement-architecture. La nouvelle couche de cache a-t-elle déplacé le breakpoint vers le haut, ou seulement déplacé le bottleneck ailleurs ?

Métriques clés de breakpoint test

1. Nombre de VUs ou RPS au point de cassure. La sortie principale. "Single node casse à 1 800 RPS avec p95 latency dépassant 2s."
2. Ce qui casse en premier. Saturation CPU ? Épuisement mémoire ? Connection pool DB ? Thread pool ? Identifier la ressource qui sature vous dit ce qu'il faut scaler.
3. Courbe de latence jusqu'au breakpoint. Scaling linéaire = sain ; coude aigu = capacité épuisée ; falaise = failure mode catastrophique.
4. Error rate vs charge. Le point où l'error rate dépasse le seuil acceptable est parfois plus tôt que le breakpoint de latence.

Comment exécuter un breakpoint test

Les mêmes scripts que load testing avec un profil de charge étagé ou rampant en douceur qui va bien au-delà du peak attendu.

Dans JMeter, utilisez le plugin Stepping Thread Group pour ajouter des VUs en steps propres (ex. +100 toutes les 60 secondes). Dans k6, configurez un scénario ramping-vus avec plusieurs étapes grimpant bien au-delà du peak attendu.

Observez les métriques en direct pendant le run. Au moment où p95 latency, error rate ou throughput divergent de la tendance, vous avez trouvé le breakpoint. Arrêtez le test avant que le système ne crashe. Vous n'avez pas besoin d'attendre l'échec catastrophique pour identifier le point de cassure.

Exécutez depuis LoadFocus quand vous avez besoin d'une génération de charge consistante ; les breakpoint tests single-laptop sont souvent peu fiables car le portable lui-même sature avant le système sous test.

Pour une analyse de breakpoint sur une infrastructure production-shape, LoadFocus propose des load testing services où des ingénieurs conçoivent le ramp, monitorent le run et rédigent le breakpoint avec une analyse de saturation infrastructure.