Qu'est-ce que le breakpoint testing ?

Qu'est-ce que le breakpoint testing ?

Le breakpoint testing (test du point de rupture) est un test de performance qui augmente la charge d'un système, par paliers contrôlés, jusqu'à sa défaillance, pour que vous connaissiez sa limite. Le résultat est un chiffre sur lequel planifier : la charge à laquelle le temps de réponse, le taux d'erreur ou le débit franchit la ligne que vous avez fixée comme échec. On parle aussi de test de capacité, de charge ponctuelle ou de limites. (Pour les breakpoints CSS du responsive design, voir design mobile-first.)

Comment se déroule un test de point de rupture

1. Définissez d'abord l'échec. Par exemple un temps de réponse p95 au-dessus d'une valeur fixée, un taux d'erreur supérieur à un pourcentage ou un débit qui cesse de croître. Sans cela, impossible de savoir quand la limite est trouvée.
2. Montez en charge progressivement. Les sauts brusques rendent difficile de savoir quand et pourquoi le système a lâché.
3. Continuez à travers la dégradation. Contrairement à la plupart des tests, celui-ci ne s'arrête pas quand le système ralentit, mais quand votre condition d'échec est remplie.
4. Arrêtez sur un seuil ou à la main. Dans k6, un seuil avec abortOnFail peut terminer l'exécution automatiquement.
5. Identifiez ce qui a saturé. CPU, mémoire, pool de connexions à la base ou pool de threads : c'est ce qu'il faut dimensionner ou corriger.

Exemple

Chiffres illustratifs, pas un benchmark. Une API garde un p95 stable à 100 utilisateurs virtuels. Vous ajoutez 50 utilisateurs par minute. Vers 400 utilisateurs, le p95 grimpe plus vite que la charge, et à 550 utilisateurs le taux d'erreur dépasse 1 %. Le point de rupture se situe autour de 550 utilisateurs, et le coude vers 400 est le chiffre de planification le plus prudent. Corrigez le goulot d'étranglement, rejouez la même rampe et vérifiez si les deux chiffres ont bougé.

Breakpoint testing, test de stress, de capacité et de pic

• Le test de capacité cherche la charge maximale qui respecte encore vos objectifs. Le breakpoint testing cherche l'endroit où ils ne sont plus respectés. Certaines sources emploient les deux termes pour la même chose.
• Un test de stress dépasse le pic attendu pour voir comment le système tombe et se rétablit. Un test de point de rupture mesure où il tombe. Voir test de charge ou test de stress (en anglais).
• Le test de pic applique un saut soudain. Le test de point de rupture monte régulièrement. Les deux reposent sur le test de charge.

Erreurs courantes

• Laisser l'autoscaling activé. Le guide k6 de Grafana prévient que les environnements élastiques peuvent continuer à grossir jusqu'à atteindre le plafond de dépenses de votre compte. Désactivez l'élasticité des composants testés, sinon vous mesurez votre budget.
• Monter trop vite en charge, ce qui masque l'emplacement du coude.
• Ne pas définir l'échec, si bien que l'exécution s'arrête quand quelqu'un se lasse.
• Un générateur de charge saturé. Si la machine qui produit la charge manque de CPU avant le système, vous mesurez le générateur, pas le système.
• Tester un système qui n'est pas le vôtre ou sans autorisation. Un test de point de rupture sert à casser : utilisez une copie de préproduction ou une fenêtre convenue, jamais un système partagé ou de production sans accord.
• Ne le lancer qu'une fois. Rejouez-le après chaque réglage pour voir si la limite a bougé.

Mener des tests de point de rupture avec LoadFocus

Dans JMeter, le plugin Stepping Thread Group ajoute des utilisateurs par lots à intervalle fixe. Dans k6, un scénario de montée en charge à plusieurs étapes fait de même. LoadFocus exécute des scripts JMeter existants et des scripts k6 en JavaScript depuis jusqu'à 25 régions cloud, et, sur les offres payantes, jusqu'à 20 000 utilisateurs virtuels simultanés par test (l'offre gratuite est limitée à 10, donc chercher un vrai plafond demande une offre payante). Vous pouvez fixer comme seuils le temps de réponse P95 et P99 maximal, le taux d'erreur maximal et le débit minimal, et les résultats tracent les erreurs et les codes de réponse en fonction du nombre d'utilisateurs virtuels, la courbe où se lit le point de rupture. Commencez par les tests de charge LoadFocus. Pour la rampe elle-même, voir la période de ramp-up JMeter (en anglais).

Questions fréquentes : breakpoint testing

Est-ce la même chose qu'un test de stress ?

Ils se recoupent. Le test de stress demande comment le système se comporte et se rétablit au-delà de ses limites. Le breakpoint testing demande où se situe exactement la limite.

Comment savoir quand arrêter le test ?

Quand votre condition d'échec définie à l'avance est remplie, par exemple un p95 au-dessus d'une limite ou un taux d'erreur supérieur à un pourcentage. Dans k6, un seuil avec abortOnFail peut arrêter l'exécution pour vous.

Faut-il le lancer en production ?

Seulement avec une approbation explicite et un plan. Le test est conçu pour provoquer des défaillances, donc une copie de préproduction est l'endroit le plus sûr.

À quelle fréquence le rejouer ?

Après des changements importants de code ou d'infrastructure, quand la charge augmente, et après un réglage, pour voir si la limite a bougé.