Otimize camada por camada — cada camada absorve carga antes que chegue à próxima. O objetivo é servir a maioria das solicitações a partir de um cache e manter PHP e o banco de dados fazendo o mínimo de trabalho possível.
Dimensione o pool conforme sua RAM e ative o para que o PHP seja compilado uma vez, não a cada solicitação:
; 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)
Se max_children for muito alto, você troca (swap) e falha; muito baixo e as solicitações ficam na fila (502s sob carga).
Essa estratificação significa que um acesso à página inicial pode retornar da borda ou do page cache sem tocar em PHP ou no DB.
Aative o slow query log para encontrar infratores, adicione indexes para consultas personalizadas e audite autoloaded options (wp_options com autoload = yes carrega em toda solicitação — dados de autoload inchados desaceleram tudo). Por fim, reduza o inchaço de plugins: cada plugin adiciona consultas e trabalho em PHP, então remova os não utilizados.
Uma solicitação WordPress é pesada em PHP e DB por padrão, então cai sob tráfego sem otimização. Caching em camadas (OPcache → object cache → page cache → CDN) mais PHP-FPM corretamente dimensionado e um banco de dados enxuto permite que um servidor único manipule ordens de magnitude mais tráfego — e o mantenha ativo durante picos.