PHP-FPM pour WordPress : tuning complet, pools dédiés et OPcache (2025)

1. Le rôle de PHP-FPM dans une stack WordPress

Lorsque quelqu’un visite votre site WordPress, le serveur web (Apache ou Nginx) ne traite pas directement le code PHP. Il délègue ce travail à PHP-FPM. On peut voir PHP-FPM comme un “pool d’ouvriers” qui prennent en charge les requêtes et renvoient le HTML final au serveur web.

Plus il y a de visiteurs simultanés, plus ces “ouvriers PHP” sont sollicités. Si le pool est trop petit : les visiteurs attendent (site lent). Si le pool est trop grand : la mémoire explose, et le serveur swappe ou tombe. Tout l’art du tuning PHP-FPM consiste à trouver le bon équilibre.

• Trop peu de processus PHP = site lent sous charge.
• Trop de processus PHP = RAM saturée > swap > serveur qui s’écroule.
• Pas assez de limites = un seul site ou plugin peut consommer toutes les ressources.

Un tuning correct de PHP-FPM est donc un levier majeur de performance serveur et de stabilité pour WordPress, surtout si vous hébergez plusieurs sites sur le même VPS.

2. Comprendre les modes de gestion PHP-FPM (pm)

PHP-FPM propose plusieurs modes de gestion des processus, contrôlés par le paramètre pm. Les trois principaux sont :

• pm = static : un nombre fixe de processus PHP, toujours en mémoire.
• pm = dynamic : un nombre de processus qui varie entre un minimum et un maximum.
• pm = ondemand : les processus PHP sont lancés uniquement lorsqu’il y a du trafic.

2.1. pm = static

Le mode static réserve en permanence un nombre fixe de processus PHP. C’est adapté aux environnements très stables et bien dimensionnés, mais peu flexible et souvent surdimensionné pour de petits serveurs.

2.2. pm = dynamic

Le mode dynamic ajuste le nombre de processus en fonction de la charge. Vous définissez un minimum, un maximum, et PHP-FPM adapte le nombre de workers dans cette plage.

Exemple :

pm = dynamic
pm.max_children = 15
pm.start_servers = 3
pm.min_spare_servers = 3
pm.max_spare_servers = 10

2.3. pm = ondemand (recommandé en multi-sites)

Le mode ondemand est souvent le meilleur choix pour des serveurs qui hébergent plusieurs sites WordPress : les processus ne sont créés que lorsqu’il y a des requêtes, et ils meurent après un temps d’inactivité.

Exemple :

pm = ondemand
pm.max_children = 10
pm.process_idle_timeout = 10s
pm.max_requests = 500

Avantage : vous ne gardez pas en mémoire des dizaines de processus PHP inactifs pour rien. Inconvénient : la première requête peut être légèrement plus lente (temps de création du process).

3. Calculer pm.max_children pour WordPress

Le paramètre pm.max_children est l’un des plus importants de PHP-FPM. Il détermine le nombre maximum de processus PHP pouvant tourner en parallèle pour un pool donné.

3.1. Comprendre la consommation mémoire d’un processus PHP

Chaque processus PHP consomme de la mémoire. Cette consommation varie selon :

• le thème et les plugins utilisés,
• la complexité des pages,
• la taille des données traitées (requêtes SQL, objets, etc.).

Un processus PHP WordPress “moyen” peut consommer entre 60 Mo et 120 Mo. Certains environnements lourds (WooCommerce + builder + extensions diverses) peuvent monter plus haut.

3.2. Formule simplifiée pour pm.max_children

Une méthode pratique consiste à estimer :

• la RAM totale disponible pour PHP-FPM,
• la RAM moyenne utilisée par un processus PHP.

Puis :

pm.max_children ≈ (RAM_disponible_pour_PHP) / (RAM_moyenne_par_processus)

Exemple concret :

• VPS avec 8 Go de RAM.
• On réserve 2 Go pour le système, 2 Go pour MySQL, 1 Go pour Redis, le reste pour PHP.
• RAM disponible pour PHP ≈ 3 Go.
• On estime un processus PHP à ~100 Mo en moyenne.

On obtient alors :

pm.max_children ≈ 3000 Mo / 100 Mo ≈ 30

Dans la vraie vie, on dimensionne un peu plus conservateur (par exemple 20–25) pour garder une marge.

3.3. Ajustements progressifs

Plutôt que de chercher la valeur parfaite du premier coup :

• Commencez avec une valeur prudente (ex. 10–15).
• Surveillez la charge CPU et la RAM avec htop / glances.
• Surveillez les logs PHP-FPM (messages “server reached max_children”).
• Ajustez progressivement à la hausse ou à la baisse.

L’objectif : éviter d’atteindre trop souvent la limite (max_children trop bas) tout en préservant la stabilité de la RAM (max_children trop élevé).

4. Pools PHP-FPM dédiés pour plusieurs sites WordPress

Si vous hébergez plusieurs sites WordPress sur le même serveur, il est fortement recommandé de créer un pool PHP-FPM par site. Cela permet d’isoler les ressources : un site mal codé ne viendra pas saturer tous les autres.

4.1. Exemple de pool PHP-FPM par site

Exemple de configuration pour un site site1 :

[site1]
user = site1
group = site1
listen = /run/php/php-fpm-site1.sock
listen.owner = www-data
listen.group = www-data
pm = ondemand
pm.max_children = 8
pm.process_idle_timeout = 10s
pm.max_requests = 500

Vous répétez ce schéma pour chaque site, avec ses propres limites. Vous pouvez ainsi :

• protéger l’ensemble de la plateforme si un site prend un pic de charge.
• dépanner plus facilement (on voit quel pool est saturé).
• adapter la config à chaque cas (gros site, petit site, admin utilisé souvent, etc.).

4.2. Liens avec Apache ou Nginx

Chaque pool est exposé via un socket ou un port, et le serveur web est configuré pour y envoyer le PHP. Par exemple, avec Apache :

ProxyPassMatch "^/(.*\.php)$" "unix:/run/php/php-fpm-site1.sock|fcgi://localhost/var/www/site1/public"

Cela permet de relier proprement un VirtualHost Apache à son pool PHP-FPM dédié.

5. OPcache : configuration recommandée pour WordPress

OPcache est un composant essentiel pour la performance PHP en production. Il met en cache le bytecode de vos scripts PHP et évite de les recompiler à chaque requête. Sans OPcache, un site WordPress avec beaucoup de plugins devient rapidement lourd.

5.1. Activer OPcache

Dans votre php.ini (ou fichier dédié à OPcache), vérifiez :

opcache.enable = 1
opcache.enable_cli = 0

5.2. Taille mémoire et nombre de fichiers

Pour un WordPress avec plusieurs plugins et quelques sites sur le même serveur, une configuration de base peut être :

opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 20000

Sur un gros parc (multi-sites, beaucoup de plugins), vous pouvez monter à :

opcache.memory_consumption = 512
opcache.max_accelerated_files = 40000

5.3. validate_timestamps : dev vs prod

En développement, vous pouvez laisser :

opcache.validate_timestamps = 1
opcache.revalidate_freq = 2

En production, pour gagner quelques millisecondes :

opcache.validate_timestamps = 0

Mais attention : il faudra purger manuellement OPcache après chaque déploiement (ou utiliser des scripts d’automatisation).

6. Logs & monitoring PHP-FPM

Un tuning PHP-FPM ne s’arrête pas à l’édition des fichiers de configuration. Il faut observer le comportement dans le temps pour vérifier que vos réglages sont adaptés.

6.1. Logs PHP-FPM

Les logs PHP-FPM se trouvent généralement dans :
/var/log/phpX.Y-fpm.log ou un fichier similaire.

Vous devez être attentif aux messages :

• server reached pm.max_children : votre pool a atteint la limite, des requêtes ont dû attendre ou ont échoué.
• Erreurs fatales ou “out of memory”.
• Délai d’exécution excessif (timeout).

6.2. Outils de monitoring côté OS

Pour vérifier la charge réelle :

• htop : voir le nombre de processus PHP, leur CPU/RAM.
• glances : vue d’ensemble du système.
• Netdata : graphiques temps réel, alertes.

Sur un serveur sain :

• La RAM ne doit pas être saturée en permanence.
• Le swap doit rester presque vide.
• La charge CPU ne doit pas exploser à chaque pic de trafic.

7. Bonnes pratiques et erreurs à éviter

Pour terminer la partie “tuning”, voici quelques bonnes pratiques simples à respecter avec PHP-FPM et WordPress.

• Évitez une seule pool pour tous les sites si vous hébergez plusieurs WordPress.
• N’augmentez pas pm.max_children à l’aveugle : surveillez la RAM.
• Ne laissez pas le log PHP-FPM se remplir sans rotation : configurez logrotate.
• Testez chaque changement de configuration sur un environnement de préproduction si possible.
• Combinez tuning PHP-FPM + Redis + cache WordPress : PHP-FPM n’est qu’une couche du puzzle.

Rappelez-vous : votre objectif n’est pas d’avoir “le plus de processus possible”, mais la meilleure stabilité possible pour votre charge réelle.

FAQ – PHP-FPM et WordPress

Quel est le meilleur mode PHP-FPM pour WordPress ?

Pour un serveur multi-sites ou mutualisé, pm = ondemand est souvent le plus adapté. Pour un gros site unique avec une charge stable, pm = dynamic peut aussi bien fonctionner. Le mode static est plutôt réservé à des environnements très maîtrisés.

Comment savoir si mon pm.max_children est trop bas ?

Si les logs PHP-FPM indiquent régulièrement server reached pm.max_children et que vous constatez des lenteurs ou erreurs 502/504, c’est un signal que la limite est atteinte trop souvent. Il faudra cependant vérifier que vous avez assez de RAM avant d’augmenter cette valeur.

Est-ce que je dois activer OPcache sur tous mes sites WordPress ?

Oui, OPcache devrait être activé sur tous les environnements de production WordPress. Les gains en performance sont significatifs, surtout avec des thèmes et plugins lourds. Veillez simplement à purger le cache en cas de mise à jour du code.

PHP-FPM suffit-il à accélérer mon site si je n’ai pas de cache WordPress ?

PHP-FPM optimisé améliorera les temps de réponse, mais sans page cache ni object cache, WordPress devra toujours faire toutes les requêtes et traitements à chaque visite. Pour des performances maximales, combinez PHP-FPM + OPcache + page cache + Redis + CDN.

Quelle version de PHP choisir pour WordPress en 2025 ?

En 2025, les versions recommandées sont PHP 8.2 et PHP 8.3, à condition que vos thèmes et plugins soient compatibles. Elles offrent de meilleures performances et un support de sécurité plus long que les versions plus anciennes.

Conclusion : un moteur PHP dimensionné pour durer

PHP-FPM est au cœur de la performance WordPress. En le configurant correctement – choix du mode pm, calcul de pm.max_children, pools dédiés, OPcache bien dimensionné – vous donnez à votre serveur la capacité de répondre rapidement et de manière stable, même sous charge.

Combiné à une base de données optimisée, à Redis et à un CDN comme Cloudflare, ce tuning PHP-FPM devient une brique essentielle d’un serveur WordPress hautement performant. Il s’intègre naturellement dans la vision plus large décrite dans le guide pilier sur l’architecture serveur du Mag Web.

Une fois votre PHP-FPM stabilisé, vous pourrez passer à d’autres optimisations : configuration Apache/Nginx, MySQL/MariaDB, Redis, multi-sites, haute disponibilité… Tout ce qui fait la différence entre un simple hébergement et une plateforme WordPress professionnelle.