Test de charge WordPress avec k6 : combien de visiteurs tient votre serveur ?

« Notre serveur tient 500 visiteurs simultanés », affirmait un client avant le lancement d’une campagne publicitaire. Ce chiffre venait d’une fiche technique d’hébergement, jamais vérifié en conditions réelles. Trois jours après le lancement de la campagne, le site est tombé à 80 visiteurs simultanés. La fiche technique ne mentait pas vraiment, elle décrivait juste un scénario qui n’avait rien à voir avec l’usage réel du site.

k6 est un outil de test de charge en ligne de commande, scriptable en JavaScript, qui permet de simuler un trafic réaliste plutôt qu’un simple bombardement de la page d’accueil. Voici comment construire un scénario qui donne des réponses utilisables, étape par étape.

Étape 1 : installer k6 et préparer un environnement de test

Ne testez jamais directement en production sans prévenir votre hébergeur : un test de charge mal calibré ressemble à s’y méprendre à une attaque par déni de service, et certains hébergeurs mutualisés coupent l’accès automatiquement. L’idéal est un environnement de recette avec les mêmes ressources que la production.

brew install k6
# ou sur Debian/Ubuntu
sudo apt install k6

Étape 2 : écrire un scénario réaliste, pas une simple boucle

L’erreur la plus commune est de taper en boucle sur l’URL d’accueil. Un visiteur réel consulte plusieurs pages, utilise parfois la recherche, ajoute un produit au panier. Un scénario k6 réaliste mélange ces actions avec des poids différents, et surtout des temps de pause entre chaque action pour simuler un comportement humain :

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

export const options = {
  stages: [
    { duration: '2m', target: 50 },
    { duration: '5m', target: 50 },
    { duration: '2m', target: 0 },
  ],
};

export default function () {
  const home = http.get('https://recette.exemple-client.test/');
  check(home, { 'accueil 200': (r) => r.status === 200 });
  sleep(2);

  const search = http.get('https://recette.exemple-client.test/?s=chaussures');
  check(search, { 'recherche 200': (r) => r.status === 200 });
  sleep(3);

  if (Math.random() < 0.2) {
    http.post('https://recette.exemple-client.test/?wc-ajax=add_to_cart', {
      product_id: '128',
      quantity: '1',
    });
  }
  sleep(1);
}

La structure en trois phases est essentielle : une montée progressive, un palier stable, une descente. C'est le palier qui donne la mesure fiable, la montée sert uniquement à ne pas fausser les résultats par un choc brutal.

Étape 3 : lancer le test et suivre les métriques en direct

k6 run scenario.js

k6 affiche en continu les métriques clés : http_req_duration (temps de réponse), http_req_failed (taux d'échec) et le nombre de requêtes par seconde effectivement tenues. Gardez un œil sur les percentiles plutôt que sur la moyenne : un p95 à 4 secondes signale un problème même si la moyenne reste correcte.

Étape 4 : lire les résultats et repérer le goulot

Une fois le test terminé, croisez les métriques k6 avec la supervision côté serveur (charge CPU, mémoire, nombre de processus PHP-FPM occupés). Le goulot n'est presque jamais celui qu'on imagine avant de mesurer :

• Si le taux d'erreur grimpe alors que le CPU reste bas, le nombre de processus PHP-FPM disponibles est probablement trop faible.
• Si le temps de réponse augmente progressivement sans erreur, la base de données sature avant le serveur web.
• Si tout reste stable jusqu'à un seuil puis s'effondre d'un coup, une limite de connexions (base de données, pool PHP-FPM) est atteinte brutalement.

Étape 5 : itérer par palier

Un seul test ne suffit pas à établir une capacité fiable. Répétez le test en augmentant le palier cible (50, puis 100, puis 200 utilisateurs simultanés) jusqu'à identifier le seuil où le taux d'erreur dépasse un niveau acceptable, par exemple 1 %. C'est ce seuil, et non une estimation théorique, qui doit figurer dans votre documentation de capacité.

Un chiffre de capacité qui n'a jamais été mesuré sous un scénario réaliste n'est qu'une opinion présentée comme un fait.

En résumé

k6 ne remplace pas une analyse fine du code ou des requêtes SQL, mais il donne une réponse concrète à une question que beaucoup de sites WordPress n'osent jamais poser : que se passe-t-il vraiment un jour de forte affluence ? Un scénario réaliste, une montée en charge progressive et une lecture attentive des percentiles suffisent à transformer une inquiétude vague en plan d'action précis avant la prochaine campagne.