Faire des tests de montée en charge sur mon site Drupal : pourquoi et comment faire ?

Dans un monde où les pics de trafic sont imprévisibles (lancement de campagne, Black Friday, actualité virale, etc.), un site Drupal qui fonctionne parfaitement à 100 visiteurs simultanés peut complètement s’effondrer à 1 000 ou 10 000. Faire des tests de charge (load testing) et des tests de stress n’est plus une option : c’est une étape obligatoire avant chaque mise en production importante.

Voici un guide complet, pragmatique et à jour en 2025 pour tester votre site Drupal comme un pro.

Pourquoi tester la montée en charge de votre site Drupal ?

• Identifier le point de rupture avant vos visiteurs
• Valider l’efficacité du cache (page cache, BigPipe, CDN, Varnish, etc.)
• Dimensionner correctement votre hébergement / autoscaling
• Détecter les requêtes SQL lentes, les boucles PHP ou les appels bloquants
• Respecter vos SLA avec vos clients (temps de réponse < 500 ms même sous forte charge)

Les outils recommandés en 2025

Recommandation : k6 est devenu le standard pour les sites Drupal en agence et chez les grands comptes (simple, performant, rapports clairs).

Étapes concrètes pour tester votre site Drupal

1. Préparer l’environnement de test

• Clonez votre site de production (base de données anonymisée si RGPD)
• Désactivez les modules de démo, debug, devel, stage_file_proxy
• Activez tous les caches (Internal Page Cache, Dynamic Page Cache, Redis/Memcached, Varnish/CDN)
• Mettez le site en mode production ($settings['cache']['bins']['render'] = 'cache.backend.redis'; etc.)

2. Identifier les scenarios critiques

Les pages les plus chargées sur un site Drupal :

• Page d’accueil
• Fiches produits / articles (avec vues, paragraphes, images derivées)
• Recherche (Search API + Solr ou Elasticsearch)
• Formulaires de contact ou d’inscription
• Panier / checkout (Drupal Commerce)

3. Écrire un script k6 simple (exemple)

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

export let options = {
  stages: [
    { duration: '2m', target: 100 },   // montée progressive
    { duration: '5m', target: 500 },
    { duration: '2m', target: 1000 },  // pic
    { duration: '3m', target: 0 },     // descente
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'], // 95% des requêtes < 500 ms
    http_req_failed: ['rate<0.01'],   // < 1% d’erreurs
  },
};

const BASE_URL = 'https://www.monsite.fr';

export default function () {
  // Page d'accueil anonyme (doit être 100% cachée)
  let res = http.get(`${BASE_URL}/`);
  check(res, { 'status 200': (r) => r.status === 200 });

  // Page article (utilisateur anonyme)
  http.get(`${BASE_URL}/article/comment-bien-choisir-son-hebergeur`);

  // Recherche
  http.get(`${BASE_URL}/recherche?keys=drupal`);

  sleep(1);
}

4. Analyser les résultats

Points clés à surveiller :

• Temps de réponse moyen et p95/p99
• Taux d’erreur HTTP > 1%
• Consommation CPU/RAM de PHP-FPM et MySQL/MariaDB
• Nombre de requêtes SQL par page (via Devel ou New Relic)
• Hit ratio du cache (Varnish, Redis)

5. Optimisations classiques Drupal après un test de charge

Fréquence recommandée

• Avant chaque grosse mise en production
• Après chaque migration majeure (Drupal 9 → 10 → 11)
• 1 fois par trimestre sur les sites à fort trafic
• Automatisé dans la CI/CD (Gitlab CI, GitHub Actions)

Conclusion

Un site Drupal bien configuré peut encaisser plusieurs milliers de visiteurs simultanés sans problème. Mais sans test de charge, vous ne le saurez jamais avant que le trafic réel arrive.

Prenez 2 heures, lancez k6 ou Gatling, et dormez tranquille : votre site ne sera plus jamais la cause d’un bad buzz le jour J.

Besoin d’un accompagnement complet (audit de performance + tests de charge + optimisations) ? Contactez-nous