# FrankenPHP worker face à une campagne de dons annuelle : le test

> Trois semaines avant la campagne de dons de fin d'année, un test de montée en charge a comparé l'ancien PHP-FPM classique au mode worker de FrankenPHP. Les chiffres ont tranché plus vite que prévu.

- Auteur : Clément Hadrot
- Publié le : 2026-02-24
- Mis à jour le : 2026-02-24
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/frankenphp-worker-campagne-dons-annuelle-test/

## L’essentiel

- Un test de charge mené trois semaines avant le pic annuel, pas la veille
- Le mode worker a mieux tenu la montée en charge progressive
- La bascule a été validée sur la base de chiffres, pas d'intuition

« Est-ce que le site tiendra le jour J ? » — la question revient chaque année avant la campagne de dons de fin d'année d'une association nationale, dont le pic de trafic annuel se concentre sur une fenêtre de quarante-huit heures autour d'un rappel envoyé par e-mail à plusieurs centaines de milliers de donateurs potentiels. Cette année, la question s'est doublée d'une autre : le passage envisagé de PHP-FPM classique vers le mode worker de FrankenPHP allait-il réellement mieux tenir la charge, ou s'agissait-il d'un pari technique non vérifié ?

Un test de charge a été programmé trois semaines avant la campagne, suffisamment tôt pour permettre un retour en arrière si les résultats s'avéraient décevants, mais suffisamment proche de l'échéance pour rester représentatif de l'état réel du code en production.

## Le protocole retenu

Avec k6, une montée en charge progressive a été simulée, de 10 à 300 utilisateurs virtuels sur trente minutes, en rejouant un scénario réaliste : arrivée sur la page d'accueil, consultation d'un projet soutenu, remplissage du formulaire de don, sans validation réelle du paiement pour ne pas polluer les données de production. Les deux configurations, PHP-FPM classique et FrankenPHP worker, ont été testées séparément sur des environnements identiques en ressources.

Le point de rupture recherché n'était pas un temps de réponse cible mais le nombre de requêtes par seconde à partir duquel le taux d'erreurs HTTP 5xx dépassait 1 %, un seuil jugé représentatif d'une dégradation réellement perceptible par les donateurs.

> L'essentiel à retenir : Un test de charge mené trois semaines avant le pic annuel, pas la veille ; Le mode worker a mieux tenu la montée en charge progressive ; La bascule a été validée sur la base de chiffres, pas d'intuition

## Résultats du test de montée en charge

| Configuration | Requêtes/seconde au point de rupture | Temps de réponse à 200 req/s |
| --- | --- | --- |
| PHP-FPM classique | 85 req/s | 1 900 ms (déjà dégradé) |
| FrankenPHP worker | 265 req/s | 420 ms |

À 200 requêtes par seconde, un niveau atteint l'an dernier dans les minutes suivant l'envoi de l'e-mail de campagne, PHP-FPM classique était déjà en zone de dégradation avancée, avec un taux d'erreurs proche de 8 %. FrankenPHP worker, à la même charge, restait sous les 420 ms de temps de réponse moyen, sans erreur mesurable.

## Ce qui explique un tel écart

- Le formulaire de don exécute plusieurs vérifications côté serveur (montant, fréquence, déduction fiscale) qui chargent à chaque requête des classes PHP nombreuses, un coût de démarrage éliminé en mode worker.
- Le pool PHP-FPM, même correctement dimensionné, épuisait ses processus disponibles plus vite face à des requêtes individuellement plus lentes à démarrer.
- FrankenPHP worker a permis de traiter davantage de requêtes concurrentes avec le même nombre de cœurs CPU alloués, sans changement d'infrastructure.

## Ce qu'il a fallu vérifier avant de valider la bascule

Le passage en mode worker impose une vigilance particulière sur l'état partagé entre requêtes, un point déjà documenté sur d'autres projets similaires. Sur ce site, un audit rapide a confirmé qu'aucune variable statique ne conservait de données sensibles au don en cours d'une requête à l'autre, un risque réel si le code n'avait pas été écrit avec cette contrainte à l'esprit.

> Un test de charge mené trois semaines avant l'échéance, et non la veille, donne le temps de revenir en arrière si les chiffres ne convainquent pas. C'est cette marge qui a permis de valider sereinement le changement.

## La bascule effective

Le mode worker a été activé une semaine avant la campagne, avec un mécanisme de repli automatique vers PHP-FPM classique en cas d'anomalie détectée par la supervision applicative, jamais déclenché durant les quarante-huit heures de pic. Le taux d'erreurs HTTP 5xx est resté sous 0,2 % pendant l'intégralité de la campagne, contre plus de 6 % l'année précédente au plus fort de l'affluence.

## Ce que le test a montré

Le mode worker de FrankenPHP a démontré, chiffres à l'appui, une capacité à absorber plus de trois fois le débit de requêtes avant dégradation, comparé à la configuration PHP-FPM classique utilisée jusque-là. Sur un événement à fenêtre courte et à trafic prévisible comme une campagne de dons annuelle, ce test préalable a transformé une décision d'infrastructure risquée en un choix validé par des chiffres reproductibles.