Charger les points d’entrée REST les plus sollicités avant un pic annoncé

GET /wp-json/reservation/v1/disponibilites?date=2024-09-14 — cet unique endpoint concentrait, d’après les statistiques de l’édition précédente, plus des trois quarts des requêtes reçues pendant la fenêtre d’ouverture des réservations d’un festival de musique en plein air. Le reste du site, y compris la page d’accueil, ne représentait qu’une fraction marginale du trafic pendant ce pic précis, connu à l’avance grâce à l’annonce publique de la date et de l’heure d’ouverture des ventes.

Plutôt que de tester une charge générique sur l’ensemble des pages du site, l’équipe a choisi de concentrer l’effort de test sur ce seul endpoint, en reproduisant fidèlement le motif d’appel observé l’année précédente plutôt qu’une charge uniforme théorique.

Identifier l’endpoint critique avant d’écrire le scénario

L’analyse des journaux d’accès de l’édition précédente a permis de reconstituer le motif exact de sollicitation : un pic brutal dans les dix premières secondes suivant l’ouverture des ventes, avec un volume attendu de 1 400 requêtes par minute sur l’endpoint de disponibilité, contre 90 requêtes par minute en fonctionnement normal du site.

Un scénario qui reproduit le motif réel, pas une montée linéaire

Le scénario de charge, écrit avec k6, reproduit ce pic brutal plutôt qu’une montée progressive artificielle, plus représentative d’un afflux organique mais moins fidèle à ce cas précis d’ouverture programmée :

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

export const options = {
  scenarios: {
    pic_ouverture_ventes: {
      executor: 'ramping-arrival-rate',
      startRate: 90,
      timeUnit: '1m',
      preAllocatedVUs: 300,
      stages: [
        { target: 1400, duration: '10s' },
        { target: 1400, duration: '2m' },
        { target: 200, duration: '3m' },
      ],
    },
  },
};

export default function () {
  const reponse = http.get(
    'https://exemple.test/wp-json/reservation/v1/disponibilites?date=2024-09-14'
  );
  check(reponse, {
    'statut 200': (r) => r.status === 200,
    'réponse en moins de 800 ms': (r) => r.timings.duration < 800,
  });
}

Ce que ce scénario ciblé a révélé

Le test a montré que l'endpoint tenait correctement jusqu'à environ 900 requêtes par minute, puis que le temps de réponse dépassait brutalement les deux secondes au-delà de ce seuil, bien avant d'atteindre le volume de 1 400 requêtes attendu. L'origine du ralentissement a été identifiée du côté d'une requête SQL non indexée sur la table de disponibilités, exécutée à chaque appel sans mise en cache, alors que le résultat ne changeait en réalité que toutes les quelques secondes.

Le correctif appliqué avant l'ouverture réelle

Un cache de courte durée (quelques secondes, via un transient WordPress) a été ajouté en amont de la requête SQL, ramenant le nombre d'appels réels à la base de données à une fraction du volume de requêtes HTTP entrantes, sans changer la fraîcheur perçue des disponibilités affichées :

function reservation_get_disponibilites( WP_REST_Request $request ) {
    $date = $request->get_param( 'date' );
    $cle_cache = 'disponibilites_' . $date;

    $disponibilites = get_transient( $cle_cache );
    if ( false === $disponibilites ) {
        $disponibilites = reservation_calculer_disponibilites( $date );
        set_transient( $cle_cache, $disponibilites, 5 );
    }

    return rest_ensure_response( $disponibilites );
}

Ce que ce scénario ciblé ne remplace pas

• Il ne remplace pas un comparatif d'outils de test de charge, choix déjà arbitré en amont sur ce projet sans lien direct avec ce scénario précis.
• Il ne constitue pas un premier scénario générique pour une équipe qui n'a jamais pratiqué de test de charge : ce point de départ suppose déjà une première familiarité avec l'outil utilisé.
• Il doit être rejoué après chaque changement significatif de la logique de disponibilité, le cache ajouté pouvant lui-même masquer une régression future si son comportement n'est pas revérifié.

Un test de charge générique rassure sur le site dans son ensemble ; un test de charge ciblé prépare réellement l'instant précis où tout se joue.

En résumé

Concentrer le test de charge sur l'endpoint réellement sollicité pendant le pic annoncé, avec un motif d'appel fidèle à l'historique réel, a permis de détecter et corriger un goulot d'étranglement avant l'ouverture des ventes. Le jour venu, l'endpoint a absorbé le pic de 1 400 requêtes par minute sans dégradation perceptible du temps de réponse.