Optimisez couche par couche — chaque couche absorbe la charge avant qu'elle ne passe à la couche suivante. L'objectif est de servir la plupart des requêtes depuis un cache et de faire en sorte que PHP et la base de données fassent le moins de travail possible.
Dimensionnez le pool selon votre RAM, et activez pour que PHP soit compilé une fois, pas à chaque requête :
; php-fpm pool: cap workers so you don't exhaust RAM
; pm.max_children = (available RAM for PHP) / (avg process size, ~50MB)
pm = dynamic
pm.max_children = 40 ; hard ceiling on concurrent PHP workers
pm.start_servers = 10
pm.min_spare_servers = 8
pm.max_spare_servers = 16
pm.max_requests = 500 ; recycle workers to avoid memory leaks
; OPcache: cache compiled bytecode in memory
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0 ; skip file-stat checks in prod (flush on deploy)
Si max_children est trop élevé, vous swappez et plantez ; trop bas et les requêtes s'accumulent (502 sous charge).
Cette stratification signifie qu'un accès à la page d'accueil peut être renvoyé depuis la périphérie ou le cache de page sans jamais toucher PHP ou la DB.
Activez le slow query log pour trouver les problèmes, ajoutez des indexes pour les requêtes personnalisées, et auditez les autoloaded options (wp_options avec autoload = yes se charge à chaque requête — les données autoload gonflées ralentissent tout). Enfin, réduisez le surpoids des plugins : chaque plugin ajoute des requêtes et du travail PHP, donc supprimez les inutilisés.
Une requête WordPress est lourde en PHP et DB par défaut, elle s'écroule donc sous le trafic sans optimisation. La mise en cache par couches (OPcache → object cache → page cache → CDN) plus un PHP-FPM correctement dimensionné et une base de données épurée permettent à un serveur unique de gérer des ordres de magnitude de trafic supplémentaires — et de rester opérationnel pendant les pics.