Tests de charge et de stress
1) Termes et objectifs
Test de charge - vérification dans la plage de fonctionnement (target RPS/concurrence) contre SLO (par exemple, p95 <200 ms, error rate <0. 5%).
Stress test - Aller au-delà (jusqu'à/au-delà de la saturation CPU/OBD/réseau), observer la dégradation et la mécanique de récupération.
Test de vitesse - surtensions brusques (× N en minutes).
Soak/Endurance est une longue course (heures/24 heures) pour trouver les fuites, la dérive de GC, la fragmentation, les files d'attente.
Test de capacité - Calcul du palier de bande passante (point de saturation) et des stocks.
Objectifs : confirmer le SLO, fixer le plateau, comprendre les goulets d'étranglement, calibrer l'échelle automatique et les limites.
2) Modèle de trafic : ouvert vs fermé
Modèle fermé (concurrency-driven) : un nombre fixe d'utilisateurs virtuels (VU), chacun après la réponse fait think time.
Modèle ouvert (arrival-rate) : intensité fixe de réception des demandes (RPS), indépendamment des réponses.
Little’s Law: `L = λ W`
« L » est le nombre moyen de requêtes simultanément servies,
« λ » est l'intensité (RPS),
« W » est le temps de réponse moyen.
D'où l'évaluation de la compétitivité du générateur : "concurrency ≈ target_RPS p95_latency'.
3) Métriques : ce que l'on mesure
SLI retards : p50/p90/p95/p99 et queue p99. 9; séparées pour les voies « chaudes » et « froides ».
Erreurs : '5xx', '4xx' (valides/non valides), timeouts, aborted.
Bande passante : RPS stable, throughput de flux/octet.
Ressources : CPU, RAM/heap, pause GC, IOPS/lat disque, bandwidth réseau, nombre de connexions/FD.
Files d'attente et backpercher : profondeur, temps d'attente, nombre de requêtes shed/limited.
Efficacité du cache : hit/miss, tempêtes de réchauffage.
Bases de données/caches/files d'attente : p95 requêtes, verrous, conflits, utilités de pool.
4) Stands et données
Équivalence de configuration : versions du logiciel, limites (uLimit, contrack), configuration JVM/GC, pool.
Topologie : LBs, CDN, WAF, TLS, les mêmes « hops » réseau.
Données : distributions réalistes (tailles des objets, clés « chaudes « / » froides », régionalité).
Démarrage froid/chaud/chaud : essais séparés ; il est obligatoire de tester les caches « froids ».
Isolation de l'arrière-plan : Désactiver les jobs/couronnes sans intérêt ou prendre en compte leur effet.
5) Scripts (profils de charge)
1. Baseline : accélération par étapes jusqu'à la cible RPS, maintien 10-30 min.
2. Ramp & Hold : croissance sans heurt jusqu'à X % au-dessus de l'objectif, rétention → analyse des résidus.
3. Spike : instantané × 2- × 5 éclats pendant 1-5 min, puis retour.
4. Stress to Failure : marches jusqu'aux échecs ; on fixe le premier point de non-exécution du SLO et le point de « rupture ».
5. Soak : 6-24 h avec variabilité du trafic (jour/nuit), suivre les faces/dérive.
6. Mixed : mélange d'endpoints par distribution réelle (Zipf/pareto), de poids différents.
6) Processus étape par étape
Identifiez les SLO et les profils de trafic cibles.
Sélectionnez le modèle de charge (ouvert/fermé), définissez le taux d'arrivée ou VU.
Préparer les données et les modes « chaud « / » froid ».
Configurer la télémétrie (tracks/métriques/logs), la corollation avec la blessure de test.
Échauffement et échauffement, collecte d'artefacts (profils CPU/heap, graphes flame, explain/slow-logs OBD).
Analyse des goulets d'étranglement, formation d'éléments d'action.
Reprogon après fixes, mise à jour de basline et capacity playbook.
7) Goulets d'étranglement et fixations typiques
Service CPU-bound : profilage → élimination des fonctions chaudes, allocations, branches ; vectorisation, structure cache-friendly.
Network/TLS : keep-alive, HTTP/2/3, connection pooling, délais corrects, réduction de la chateté.
Bases de données : index, batterie, requêtes préparées, pool de connexions, séparation R/W, mise en cache des résultats, déduplication des requêtes.
Caches : taille, TTL, request coalescing, protection contre les tempêtes, warming, boules régionales.
Files d'attente/courtiers : limites d'acceptation/parallélisme, taille des trampolines, idempotent consommateurs, plafonds DLQ.
Garbatedge/pauses : tuning GC, location de tampons, object pooling dans des limites raisonnables.
I/O/disque : entrée/sortie asynchrone, compression, compression des réponses avec un niveau raisonnable.
8) Limites et protection
Budget temporel : de haut en bas pour éviter les cascades.
Rate limit/token-baquets : dégradation prévisible au lieu de « longue mort ».
Circuit breaker et shading de faible priorité à saturation.
Backpressure : signaux et limitation du parallélisme à l'intérieur de la chaîne.
Bulkheads : isolation des pools sous endpoints critiques.
Idempotency : clés pour des répétitions sécurisées sous les retraits.
9) Outils et quand les choisir
k6 est un JS laconique, un excellent support pour le rate arrival, l'intégration et les graphiques.
Gatling - Scala DSL, générateur haute performance.
JMeter est un écosystème flexible et riche ; Pratique pour les protocoles/plugins.
Locust - script Python, pratique pour la logique complexe de flow utilisateur.
Vegeta/hey/wrk sont des microbenches et des points sur HTTP.
tc/netem, toxiproxy - injection de dégradation du réseau.
Flamegraph/profiler - recherche des « endroits chauds » CPU/heap.
10) Exemples (sketches)
k6 (modèle ouvert, mix d'endpoints)
javascript import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
scenarios: {
open_model: {
executor: 'constant-arrival-rate',
rate: 800, timeUnit: '1s', duration: '20m',
preAllocatedVUs: 500, maxVUs: 2000
}
},
thresholds: {
'http_req_duration{kind:hot}': ['p(95)<200'],
'http_req_failed': ['rate<0. 005']
}
};
export default function () {
const r = Math. random();
let res;
if (r < 0. 6) {
res = http. get('https://svc/api/hot', { tags: { kind: 'hot' }});
} else if (r < 0. 9) {
res = http. get('https://svc/api/warm', { tags: { kind: 'warm' }});
} else {
res = http. post('https://svc/api/heavy', JSON. stringify({ n: 1000 }), { headers: { 'Content-Type': 'application/json' }});
}
check(res, { 'status is 2xx': (r) => r. status >= 200 && r. status < 300 });
sleep(0. 2);
}Gatling (étapes et spike)
scala setUp(
scn. inject(
rampUsersPerSec(50) to 500 during (10 minutes),
constantUsersPerSec(500) during (20 minutes),
spikeUsers(2000). during(30. seconds)
)
). protocols(http. baseUrl("https://svc"))Plan de charge (squelette YAML)
yaml profile: "mix-traffic"
targets:
- endpoint: GET /api/hot weight: 0. 6
- endpoint: GET /api/warm weight: 0. 3
- endpoint: POST /api/heavy weight: 0. 1 schedule:
- step: { rps: 300, hold: 10m }
- step: { rps: 600, hold: 10m }
- step: { rps: 900, hold: 10m }
guardrails:
slo:
p95_ms: 200 error_rate: 0. 5%
abort_if:
- metric: error_rate op: ">"
value: 2%
window: 2m11) Automatisation et cycle de vie
Perf-smoke dans chaque PR (courte course d'endpoints clés).
« Capacity » de nuit sur le steadge avec des rapports et des artefacts de profil.
Gates en CI/CD : fail bill à la régression p95/p99> X % de basline ou de croissance error rate.
Versioner les baslines et stocker les profils/flûtes comme artefacts.
Tags de pertinence : Quel service/endpoint est couvert, quel profil de trafic utilisé.
12) Anti-modèles
Le générateur et le service testé sur une seule machine → des résultats déformés.
Seul le modèle fermé (VU) pour les bacs API → la sous-estimation des queues et la mauvaise estimation.
Pas de démarrage à froid.
Aucune distribution réaliste (toutes les demandes sont les mêmes).
Pas de télémétrie (uniquement RPS/latency côté générateur).
Comparaison sans baslines stables et contrôle de l'environnement.
« Optimisation » via un délai plus long au lieu de corriger la cause.
13) Chèque de l'architecte
1. Définition du SLO et de la charge type/crête ?
2. Le modèle correct (ouvert/fermé) est-il sélectionné et le profil de trafic est-il peint ?
3. Le stand est équivalent en configues et en topologie, y a-t-il un mode froid/chaud ?
4. La télémétrie et les profils sont inclus, les étiquettes de la blessure sont-elles apposées ?
5. Essais : baseline/ramp/spike/stress/soak - couverts ?
6. Des points de saturation sont fixés et un stock est prévu (margin de sécurité) ?
7. Les limites, les breakers, le backpercher, l'idempotency, les polices de shading sont-ils configurés ?
8. Y a-t-il des gates CI pour régression p95/p99 et error rate, baslines versionées ?
9. Après les fiches - refonte et mise à jour du playbook en puissance ?
10. Plan de mise à l'échelle automatique et de mode d'urgence documenté ?
Conclusion
Les tests de charge et de stress ne sont pas des « courses » ponctuelles, mais une pratique d'ingénierie continue. Un modèle de trafic réaliste, des stands corrects, la télémétrie et l'automatisation en CI/CD transforment la performance de la « magie secrète » en une capacité contrôlée par métrique : vous savez où est votre plafond, à quel point le stock est sûr et quels changements améliorent vraiment l'expérience utilisateur.