Verrouiller un serveur avant l’ouverture d’une billetterie très attendue

12 000 connexions simultanées attendues dans les cinq premières minutes : c’est l’estimation communiquée par l’équipe billetterie d’un festival avant l’ouverture des ventes pour sa programmation phare de l’année. Un chiffre qui, ramené à la capacité habituelle du serveur hébergeant le site vitrine et son module de réservation, imposait une préparation méthodique bien en amont du jour J.

La sécurisation applicative de la billetterie elle-même — anti-bot, limitation du nombre de billets par personne, protection contre la revente automatisée — relève d’un chantier distinct, mené en parallèle mais non traité ici. Cette checklist se concentre exclusivement sur les réglages serveur permettant d’absorber le pic de connexions sans s’effondrer.

Pourquoi le serveur cède avant l’application

Sur ce type d’événement, le goulot d’étranglement n’est presque jamais le code de la billetterie elle-même, mais le nombre de connexions que le serveur peut traiter simultanément avant de mettre les visiteurs en attente. Un réglage par défaut, pensé pour un trafic quotidien modeste, sature en quelques secondes face à un afflux concentré sur une poignée de minutes.

Checklist de verrouillage avant ouverture

1. Augmenter pm.max_children côté PHP-FPM, calculé selon la mémoire réellement disponible divisée par la consommation moyenne d’un processus PHP, mesurée au préalable avec ps aux | grep php-fpm.
2. Passer le mode de gestion PHP-FPM en static plutôt que dynamic pendant la fenêtre à risque, pour éviter le délai de démarrage de nouveaux processus au moment précis où ils sont le plus nécessaires.
3. Vérifier la limite de connexions du serveur de base de données, avec max_connections sous MySQL ou MariaDB, dimensionnée pour supporter le nombre de processus PHP maximal sans rejet de connexion.
4. Mettre en cache intégral la page d’accueil et les pages de programmation, seules pages consultées en masse avant l’ouverture effective des ventes, en excluant explicitement le module de réservation lui-même du cache de page.
5. Préparer une page d’attente statique, générée à l’avance et servie directement par le serveur web sans passer par PHP, activable en un clic en cas de dépassement de capacité malgré tout.
6. Augmenter la limite de descripteurs de fichiers ouverts (ulimit -n) au niveau du système, un réglage souvent oublié qui peut provoquer des erreurs silencieuses bien avant que la charge processeur ne devienne critique.
7. Désactiver temporairement les tâches de fond non essentielles, sauvegardes automatiques et cron WordPress inclus, pour ne pas consommer de ressources serveur pendant la fenêtre critique.
8. Configurer une limitation de débit au niveau du serveur web (limit_req sous Nginx), pour lisser les pics de requêtes automatisées sans bloquer les visiteurs humains normaux.
9. Tester la bascule vers la page d’attente en conditions réelles au moins une fois avant le jour J, pour s’assurer qu’elle s’active sans erreur au moment critique.
10. Prévenir l’hébergeur de la fenêtre d’ouverture prévue, en particulier sur une offre mutualisée où un pic isolé peut déclencher une action automatique de protection anti-abus côté hébergeur, si ce dernier n’est pas informé du contexte.

Le réglage limit_req en détail

limit_req_zone $binary_remote_addr zone=billetterie:10m rate=5r/s;

server {
    location /reservation/ {
        limit_req zone=billetterie burst=10 nodelay;
        try_files $uri $uri/ /index.php?$args;
    }
}

Ce réglage limite chaque adresse IP à cinq requêtes par seconde vers le module de réservation, avec une tolérance de dix requêtes en rafale traitées sans délai supplémentaire. L’objectif n’est pas de bloquer les visiteurs légitimes, qui n’atteignent presque jamais ce débit dans une navigation normale, mais de contenir les scripts automatisés qui rafraîchissent la page de façon agressive dans l’espoir de décrocher un billet.

Le jour J : surveiller plutôt que subir

Pendant la fenêtre d’ouverture elle-même, une supervision en direct du nombre de processus PHP-FPM occupés, de la charge du serveur de base de données et du taux d’erreur HTTP renvoyé par le serveur web a été maintenue en continu, avec une personne dédiée à cette seule surveillance, prête à activer la page d’attente au premier signe de saturation plutôt que d’attendre une panne complète.

Un repère qu’on retient de ce type d’événement : mieux vaut une page d’attente propre et annoncée qu’un serveur qui répond par intermittence, qui donne l’impression au visiteur que son navigateur, et non le serveur, est en cause.

En résumé

Verrouiller un serveur avant l’ouverture d’une billetterie à forte affluence tient à une série de réglages précis, testés à l’avance plutôt qu’improvisés le jour même : dimensionnement des processus PHP, capacité de la base de données, mise en cache ciblée et limitation de débit. Une checklist suivie point par point transforme un pic redouté en non-événement technique, ce qui reste le meilleur résultat possible pour ce type d’ouverture.