Load Testing Patterns

Le load testing mesure comment un système se comporte sous charge concurrente. Ne pas confondre avec unit/integration tests (fonctionnel) ou stress tests (casser le système).

1. Types de tests

Type	Objectif	Durée	Charge
Baseline	Mesurer la perf de référence	5 min	1 user
Load test	Valider la perf à charge attendue	15-30 min	X users (capacity cible)
Stress test	Trouver le point de rupture	30-60 min	X × 2 à X × 5
Spike test	Résilience à un pic soudain	5-10 min	0 → X × 3 en 30s
Soak test (endurance)	Memory leaks, resource leaks	2-24h	X users (stable)

2. k6 (recommandé)

# Install
brew install k6           # macOS

Script de base

// loadtest.js
import http from 'k6/http'
import { sleep, check } from 'k6'

export const options = {
  stages: [
    { duration: '30s', target: 10 },
    { duration: '2m', target: 100 },
    { duration: '30s', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1000'],
    http_req_failed: ['rate<0.01'],
  },
}

export default function () {
  const res = http.get('https://api.example.com/products')
  check(res, {
    'status is 200': (r) => r.status === 200,
    'body contains items': (r) => r.body.includes('"items"'),
  })
  sleep(1)
}

k6 run loadtest.js

Scénario réaliste (multi-étapes)

import http from 'k6/http'
import { sleep, check, group } from 'k6'

export const options = {
  scenarios: {
    browse: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '1m', target: 50 },
        { duration: '5m', target: 50 },
        { duration: '1m', target: 0 },
      ],
      gracefulRampDown: '30s',
    },
  },
  thresholds: {
    'http_req_duration{group:::browse homepage}': ['p(95)<200'],
    'http_req_duration{group:::view product}': ['p(95)<300'],
    http_req_failed: ['rate<0.01'],
  },
}

const BASE_URL = 'https://api.example.com'

export default function () {
  group('browse homepage', () => {
    const res = http.get(`${BASE_URL}/`)
    check(res, { 'home 200': (r) => r.status === 200 })
    sleep(Math.random() * 3 + 1)
  })

  group('view product', () => {
    const res = http.get(`${BASE_URL}/products/p1`)
    check(res, { 'product 200': (r) => r.status === 200 })
    sleep(Math.random() * 5 + 2)
  })

  group('add to cart', () => {
    const res = http.post(
      `${BASE_URL}/cart/add`,
      JSON.stringify({ productId: 'p1', qty: 1 }),
      { headers: { 'Content-Type': 'application/json' } }
    )
    check(res, { 'cart 200': (r) => r.status === 200 })
    sleep(1)
  })
}

Thresholds = SLO-driven

thresholds: {
  'http_req_duration': [
    { threshold: 'p(95)<500', abortOnFail: true },
    { threshold: 'p(99)<1500', abortOnFail: false },
  ],
  'http_req_failed': ['rate<0.01'],
  'checks': ['rate>0.99'],
}

Quand un threshold échoue, k6 exit avec un code non-zero → utile en CI.

3. Locust (Python)

pip install locust

# locustfile.py
from locust import HttpUser, task, between

class WebsiteUser(HttpUser):
    wait_time = between(1, 5)

    def on_start(self):
        self.client.post("/login", json={"email": "test@example.com", "password": "xxx"})

    @task(3)
    def view_homepage(self):
        self.client.get("/")

    @task(2)
    def view_product(self):
        self.client.get("/products/p1")

    @task(1)
    def checkout(self):
        self.client.post("/cart/add", json={"productId": "p1"})

locust -f locustfile.py --host https://api.example.com
# Ouvre http://localhost:8089 avec UI

Avantages Locust :

• Python (pour les équipes non-JS)
• UI web pour contrôler la charge en live
• Distributed mode (plusieurs workers)

4. Gatling (haute throughput)

Gatling utilise Scala pour définir les simulations avec une DSL fluent. Un scénario enchaîne des actions HTTP (http("home").get("/")) avec des pauses, et une setUp configure l'injection profile (rampUsers(100).during(30.seconds), constantUsersPerSec(10).during(5.minutes)). Les assertions définissent les SLO (p95 < 500ms, error rate < 1%).

Avantages Gatling :

• Très haute throughput (100k+ req/s sur une machine modeste)
• Rapports HTML riches
• Simulation par "injection profile"

Inconvénient : Scala = learning curve.

5. Artillery (YAML simple)

# loadtest.yml
config:
  target: https://api.example.com
  phases:
    - duration: 60
      arrivalRate: 10
      rampTo: 50
      name: Ramp up
    - duration: 300
      arrivalRate: 50
      name: Steady
  ensure:
    p95: 500
    maxErrorRate: 1

scenarios:
  - name: Browse
    flow:
      - get:
          url: /
      - think: 2
      - get:
          url: /products/p1
      - think: 3
      - post:
          url: /cart/add
          json:
            productId: p1
            qty: 1

npm install -g artillery
artillery run loadtest.yml

Avantage : YAML minimal, idéal pour des tests rapides sans écrire de code.

6. wrk (minimal CLI)

brew install wrk

# 100 connexions, 4 threads, 30 secondes
wrk -c 100 -t 4 -d 30s https://api.example.com/

# Avec un script Lua custom
wrk -c 100 -t 4 -d 30s -s custom.lua https://api.example.com/

Ultra simple, parfait pour un quick benchmark en 10 secondes.

7. Métriques à surveiller

Métriques client (côté load tester)

Métrique	Cible typique
Latency p50 (median)	< 100ms
Latency p95	< 500ms
Latency p99	< 1000ms
Latency p99.9	< 3000ms
Throughput (RPS)	Varié selon use case
Error rate	< 1 %
Connections active	< capacity limit

Métriques serveur (à corréler)

Métrique	Alerte si
CPU	> 70 % sustained
Memory	> 80 %
Disk I/O	> 70 % utilization
Network out	> 80 % bandwidth
DB query time	p95 > 100ms
DB connections	> 80 % pool
GC pauses	> 100ms

8. CI integration (GitHub Actions)

# .github/workflows/loadtest.yml
name: Load test

on:
  pull_request:
    paths:
      - 'api/**'

jobs:
  loadtest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to preview env
        run: echo "Deploy script here"

      - name: Run k6 load test
        uses: grafana/k6-action@v0.3.1
        with:
          filename: loadtest.js
          flags: --out json=results.json

      - name: Upload results
        uses: actions/upload-artifact@v4
        with:
          name: k6-results
          path: results.json

9. Bottleneck identification

Quand un load test révèle un problème, chercher le bottleneck :

1. CPU spike serveur → profiler (node --prof, py-spy, async-profiler Java)
2. Memory growth (soak test) → heap dump + analyse (hprof, jemalloc)
3. DB slow queries → EXPLAIN ANALYZE + indexes manquants
4. Connection pool exhausted → augmenter pool size ou réduire query time
5. Network I/O → optimiser payload (compression, pagination, GraphQL)
6. External API timeout → caching, circuit breaker, retry budget
7. GC pauses (Java, Node) → tuning heap size, pool sizing

10. Capacity planning

Process type :

1. Baseline — 1 user, noter latence moyenne
2. Load test — ramp up jusqu'à la charge cible (ex. 1000 RPS)
3. Stress test — ramp up jusqu'à failure point
4. Formule : capacity = (max RPS soutenable) / (RPS moyen par user) = users simultanés max
5. Safety margin : provisionner 2x la capacity cible pour absorber les spikes

Anti-patterns

1. Tester en prod sans warning — crash possible, clients impactés
2. Test depuis un seul poste local → bottleneck sur le laptop, pas le serveur
3. Test sans ramp-up → spike soudain, pas réaliste
4. Pas de think time (sleep entre requêtes) → utilisateurs irréalistes
5. Charge inférieure à celle de prod → faux sens de sécurité
6. Ignorer le p99/p99.9 → seulement regarder la moyenne masque les spikes
7. Pas de corrélation métriques client ↔ serveur → impossible d'identifier le bottleneck
8. Load test contre un env différent de la prod (DB vide, cache chaud) → résultats non-représentatifs
9. Pas de baseline historique → impossible de comparer avant/après une optimisation
10. Tests one-shot sans CI → performance regress non détectée

Checklist

• Tool choisi selon le stack et l'équipe (k6 recommandé par défaut)
• Environnement dédié (pas la prod)
• Données de test réalistes (volume, shape)
• Scénarios multi-étapes qui reflètent le user journey
• Ramp-up progressif
• Think time entre les requêtes
• Thresholds SLO-based (p95, p99, error rate)
• Métriques serveur monitorées en parallèle
• Durée adéquate (au moins 10 min pour une steady state)
• Résultats exportés (JSON, HTML, CSV)
• CI integration pour prévenir les regressions
• Baseline historique stockée pour comparaison

Quand déléguer

• E2E testing → skill e2e-testing dans atum-stack-web
• Unit testing → skills *-testing par langage dans les plugins stack
• Perf profiling → agent performance-optimizer
• DB query optimization → database-optimizer
• Monitoring observability → skills posthog-instrumentation, sentry-*

Ressources

• https://k6.io/docs/
• https://locust.io/
• https://gatling.io/docs/gatling/
• https://www.artillery.io/docs
• https://github.com/wg/wrk
• https://grafana.com/docs/k6/latest/