Tests de charge et stress

Tests de charge et stress

1) Pourquoi est-ce nécessaire

• Confirmer la capacité (combien de sessions RPS/concurrentielles le système supportera avec un SLO donné).
• Trouver des goulots de bouteille (CPU/IO/OBD/filets/verrous/pools).
• Configurer les budgets de performance et les « gates » dans CI/CD.
• Réduire le risque de libération (régression p95/p99, augmentation des erreurs au pic).
• Prévoir la capacité/le coût (skale out et réserves).

2) Types de tests de perf

Charge (charge de travail) : trafic réaliste proche des pics ; validation de SLO.
Stress (stress) : croissance jusqu'à/au-dessus de la limite → comportement lors de la dégradation où il se brise.
Spike (impulsion) : surtension rapide → élasticité/auto-ski.
Soak/Endurance (longue durée) : heures/24 heures → fuites, fragmentation, dérive de latitude.
Capacity/Scalability : comment le throughput/latency change dans l'échelle-out ; la loi Amdal/Gustafson.
Smoke perf : courte course « fumée » à chaque sortie (performance-sanity).

3) Modèles de génération de trafic

Modèle fermé (VU fixe/concurrency) : 'N'utilisateurs, chacun fait des requêtes → file d'attente dans le client. Risque de cacher la surcharge.
Modèle ouvert (rate arrival) : flux de demandes avec une intensité de λ (req/s), comme dans la vie réelle. Plus correct pour les API publiques.

Loi de Little : « L = λ × W ».
Pour le pool/service : parallélisme minimum ≈ 'λ × W' (ajouter 20-50 % du stock).
Où 'λ' est throughput, 'W' est le temps de service moyen.

4) Profils de charge et scénarios

User journey mix : parts de script (login, browse, deposit, checkout...).
Think-time : pauses de l'utilisateur (distributions : exponentielles/lognormales).
Profil de données : taille des réponses, payload, variabilité des paramètres.
Corrélation : liez les étapes (cookies/tokens/ID) comme dans un flow réel.
Cash froid/chaud/chaud : des courses séparées.
Read vs Write : équilibre lectures/enregistrements, idempotence pour les rétrogrades.
Multi-région : RTT, distribution POP/ASN.

5) Environnement de test

Isolation : le stand est proche de la vente par topologie/réglages (mais pas « frapper » la prod).
Données : masque PII, volumes, indices comme dans la vente.
Générateurs de charge : ne sont pas en appui sur le CPU/réseau ; runners distribués, synchronisation temporelle.
Observabilité : métriques/trajets/logs, synthétiques sur le périmètre, exportations de profils CPU/heap.

6) Métriques et SLI

Throughput : RPS/transactions en secondes.
Latency: p50/p95/p99, TTFB, server time vs network.
Errors : proportion d'erreurs de domaine 5xx/4xx.
Saturation : CPU, load avg, GC, IOps/latence, réseau, pool wait.
Business SLI : succès du dépôt ≤ 5s, confirmation de commande ≤ 2s.

Prenez les seuils du SLO (p. ex. "99. 95 % ≤ 300 ms"), surveillez le taux de burn pendant la course.

7) Recherche de goulets d'étranglement (méthodologie)

1. Réchauffez le système de façon stable de 60 à 80 % de la charge cible.
2. Agrandissez les marches (ramp) → fixez l'endroit où p95/p99 grandit et le taux d'erreur.

• files d'attente dans les pools (DB/HTTP),
• la croissance du WAIT/lock (OBD),
• GC-pauses/heap,
• réseau retransmits/packet loss,
• latence de disque/défauts de cache.
• 4. Localiser : recherche binaire sur le chemin de requête, profileurs (CPU/alloc/lock-profile).
• 5. Fixez la « bouteille » → le tuning → la répétition de la course.

8) Comportement stressé

Graceful degradation : limites, circuits-breakers, files d'attente avec backpressure, mode « accepté en cours de traitement ».
Retrai : 1 maximum, idempotent seulement ; jitter ; budget rétroactif ≤ 10 % du RPS.
Fail-open/Fail-closed : pour les dépendances non critiques, admettez fail-open (cache/bouchons).
Cascading failure : isolation des pools/quotas (bulkhead), temporisation rapide, désactivation « fluide » des fonctions (flags de fonction).

9) Outils (sélection par tâche)

k6 (JavaScript, open/open-model, rapide, pratique en CI).
JMeter (riche en écosystème, GUI/CLI, plugins, mais plus lourd).
Gatling (Scala DSL, haute performance).
Locust (Python, flexibilité de script).
Vegeta/hey/wrk (micro-benchi et contrôle rapide).

Règle : un outil « principal » + CLI léger pour smoke-perf en PR.

10) Exemples (extraits)

10. 1 k6 (modèle ouvert avec rate arrival)

js import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
scenarios: {
open_model: {
executor: 'ramping-arrival-rate',
startRate: 200, timeUnit: '1s',
preAllocatedVUs: 200, maxVUs: 2000,
stages: [
{ target: 500, duration: '5m' },  // до 500 rps
{ target: 800, duration: '5m' },  // стресс
{ target: 0,  duration: '1m' }
]
}
},
thresholds: {
http_req_duration: ['p(95)<300', 'p(99)<800'],
http_req_failed: ['rate<0.005'],
},
};

export default function () {
const res = http.get(`${__ENV.BASE_URL}/api/catalog?limit=20`);
sleep(Math.random() 2); // think-time
}

10. 2 JMeter (idée de profil)

Thread Group + Stepping Thread или Concurrency Thread (open-like).
HTTP Request Defaults, Cookie Manager, CSV Data Set.
Backend Listener → InfluxDB/Grafana; Assertions par temps/code.

10. 3 Locust (Python)

python from locust import HttpUser, task, between class WebUser(HttpUser):
wait_time = between(0.2, 2.0)
@task(5)
def browse(self): self.client.get("/api/catalog?limit=20")
@task(1)
def buy(self): self.client.post("/api/checkout", json={"sku":"A1","qty":1})

11) Données, corrélation, préparation

Données seed : catalogues, utilisateurs, bilans, jetons - comme dans la vente.
Masquage/anonymisation des IPI ; génération de synthétiseurs au-dessus des distributions réelles.
Corrélation : extrayez les ID/tokens des réponses (RegBou/JSONPath) et utilisez-les dans les étapes suivantes.

12) Observabilité pendant les courses

RED-dashboards (Rate, Errors, Durée) le long des itinéraires.
Exemplars : passage des métriques aux pistes (trace_id).
Logs d'erreur : sampling + agrégation, duplicata/idempotence.
Système : CPU/GC/heap, disques/réseau, pool wait.
OBD : top demandes, verrous, index-scans, blog.

13) Automatisation et performances gates

CI : courtes courses sur merge (par exemple k6 2-3 minutes) avec seuils.
Nightly/Weekly : soak/stress long dans un environnement séparé ; rapports et tendances.
Sorties canaries : analyse SLO (error-rate, p95) comme « gate » de la promotion.
Régressions : baseline vs bill courant ; alertes avec détérioration> X %.

14) Planification de la capacité et des coûts

Courbes de throughput→latency : définir knee point (genou) - après il p99 grandit fortement.
Skale-out : mesurer l'efficacité de mise à l'échelle (delta RPS/delta nœuds).
Coût : « RPS par $/heure », réserve pour les événements de pointe + réserve de DR.

15) Anti-modèles

Frappez la prode sans contrôle ou testez dans un environnement « vide » qui ne ressemble pas à la prod.
Modèle fermé avec VU fixe qui cache la surcharge.
L'absence de think-time/données → des succès de cache irréalistes ou vice versa - une tempête vers les sources.
Un script « /ping »au lieu d'un flow personnalisé.
Manque d'observabilité : « nous ne voyons que le RPS et le retard moyen ».
Retraits incontrôlables → samo-DDoS.
Mélanger le test et les optimisations sans fixer les hypothèses/changements.

16) Chèque-liste (0-30 jours)

0-7 jours

Définissez le SLI/SLO et les profils de trafic cibles (mix, think-time, données).
Sélectionnez l'outil (k6/JMeter/Locust), soulevez les dashboards RED.
Préparez le stand et les données seed, désactivez les limites/captches tiers.

8-20 jours

Construisez des scénarios : open-model (rate arrival), froid/cache chaud/chaud.
Lancez load → stress → spike ; fixez le point de connaissance et les goulets d'étranglement.
Introduire les gates de performance dans le CI (micro-course).

21-30 jours

Soak-test 4-24 h : fuites/dérive GC, stabilisation.
Documentez les limites, le plan de capacité, les illustrations « RPS→p95/oshibki ».
Préparez un runbook « comment augmenter les limites/skale » et « comment dégrader ».

17) Métriques de maturité

Il existe des profils réalistes (mix, think-time, data) qui couvrent ≥ 80 % du trafic.
RED-dashboard + trace sont connectés pour tous les tests.
Les gates de performance bloquent les sorties lors de la régression de p95/erreurs.
La capacité et le point de connaissance sont documentés sur les services clés.
Soak/stress mensuels et rapports dynamiques.
La résistance au « spike » est confirmée par le skate automatique et l'absence de cascade-fail.

18) Conclusion

Les tests de charge sont une pratique d'ingénierie régulière, pas une « mesure » unique. Modélisez les utilisateurs réels (open-model), mesurez ce qui reflète l'expérience client (SLI/SLO), gardez l'observation et les « gates » dans CI/CD, effectuez des tests stress/spike/soak et fixez le point knee. Ensuite, les événements de pointe et les « cygnes noirs » se transforment en scénarios gérables et les performances en paramètres prévisibles et mesurables de votre plateforme.