Apache MPM event en 2026 — dimensionner le pool de threads que nous faisons réellement tourner

À chaque fois que nous onboardons un nouveau client faisant tourner Apache httpd, la première chose que nous regardons est la configuration MPM. Environ 70 % du temps c'est encore prefork, généralement parce que l'install a été bootstrappée il y a des années quand quelqu'un avait besoin de mod_php et n'y est jamais revenu. Encore 20 % c'est worker avec les valeurs par défaut du package distrib. Peut-être 10 % c'est event — et de ceux-là, peut-être la moitié est dimensionnée correctement.

Les trois MPMs, en bref

• prefork — un processus par requête, pas de threads. Empreinte mémoire énorme. A survécu parce que mod_php n'est pas thread-safe.
• worker — plusieurs processus, chacun avec plusieurs threads. Un thread est occupé pour toute la durée de vie de la connexion, y compris le keep-alive inactif.
• event — les mêmes threads que worker, mais les connexions keep-alive inactives sont rendues à un listener dédié utilisant epoll/kqueue. Un thread n'est occupé que lorsqu'il fait réellement du travail.

Pour les workloads keep-alive — et HTTP/2 signifie que tout est keep-alive en 2026 — event est matériellement meilleur que worker. Sur un site occupé avec 5 000 connexions concurrentes, c'est la différence entre avoir besoin de 5 000 threads et peut-être 400.

Les chiffres qui comptent vraiment

Ce que nous déployons sur une machine Apache 4-vCPU / 8 Go typique servant PHP-FPM :

<IfModule mpm_event_module>
    ServerLimit              16
    ThreadsPerChild          64
    MaxRequestWorkers        1024
    MaxConnectionsPerChild   10000
    AsyncRequestWorkerFactor 2
</IfModule>

MaxRequestWorkers est le bouton célèbre — mais sur event il contrôle les workers actifs, pas le total des connexions. AsyncRequestWorkerFactor est le multiplicateur qui permet au listener de tenir bien plus de keep-alives inactifs que MaxRequestWorkers ne le suggérerait.

Le post Medium complet parcourt :

• Pourquoi prefork doit partir (et la migration PHP-FPM qui remplace mod_php)
• Comment dimensionner ServerLimit × ThreadsPerChild contre votre concurrence réelle
• Le raisonnement MaxConnectionsPerChild — et pourquoi la valeur par défaut de 0 est fausse
• Lire mod_status + apachetop pour vérifier votre tuning sous charge réelle
• Là où event perd encore face à nginx, et là où il ne perd pas

Suite sur Medium.