Test de charge

Le test de charge (load testing) soumet un système au trafic que vous attendez réellement, en général le pic de charge normal, et mesure son comportement : percentiles de latence, taux d’erreur, débit et consommation de ressources. La question à laquelle il répond est : « atteint-il ses objectifs de performance sous la charge que nous prévoyons ? » Il ne s’agit pas de faire tomber le système ; ça, c’est le test de stress.

Exemple (k6)

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

export const options = {
  stages: [
    { duration: '2m', target: 100 }, // ramp up to 100 virtual users
    { duration: '10m', target: 100 }, // hold at expected peak
    { duration: '1m', target: 0 },    // ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1200'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.get('https://staging.example.com/api/products');
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1); // think time between iterations
}

Si l’un des seuils est dépassé, k6 se termine avec un code de sortie non nul : le même script peut donc servir de barrière (gate) dans la CI.

Charge, stress, endurance et pic

Type	Profil de charge	Question à laquelle il répond
Charge	Pic attendu, maintenu stable	Atteignons-nous les objectifs au pic normal ?
Stress	Croissante au-delà de l’attendu	Où et comment le système casse-t-il, et se rétablit-il ?
Endurance (soak)	Charge normale pendant des heures	Se dégrade-t-il avec le temps (fuites, épuisement de pool) ?
Pic (spike)	Saut brutal, puis baisse	Survit-il à une rafale et revient-il à la normale ?

Bien le faire

• Modélisez le trafic réel. Utilisez la répartition des endpoints, des tailles de payload et des temps de réflexion observée dans les analytics de production, pas une seule URL martelée en boucle.
• Utilisez un environnement proche de la production. Les résultats d’une machine de staging sous-dimensionnée ne vous renseignent que sur cette machine.
• Jugez sur les percentiles, pas sur les moyennes. Une moyenne masque la queue lente dont les utilisateurs se plaignent réellement.
• Surveillez aussi le côté serveur. CPU, mémoire, connexions à la base de données et profondeur des files d’attente expliquent pourquoi la latence a bougé.
• Fixez les objectifs d’abord. Sans objectif explicite comme « p95 sous 500 ms à 200 requêtes par seconde », un test de charge produit des chiffres mais aucun verdict.