Optimice capa por capa — cada capa absorbe la carga antes de que llegue a la siguiente. El objetivo es servir la mayoría de las solicitudes desde un caché y mantener PHP y la base de datos haciendo la menor cantidad de trabajo posible.
Dimensione el grupo de acuerdo con su RAM y habilite para que PHP se compile una vez, no en cada solicitud:
; 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 es demasiado alto, cambia e falla; demasiado bajo y las solicitudes se colean (502s bajo carga).
Esta estratificación significa que una visita a la página principal puede regresar desde el perímetro o la caché de página sin tocar PHP o la base de datos en absoluto.
Habilite el slow query log para encontrar infractores, agregue indexes para consultas personalizadas y audite autoloaded options (wp_options con autoload = yes carga en cada solicitud — los datos de carga automática hinchados ralentizan todo). Finalmente, reduzca el exceso de plugins: cada plugin agrega consultas y trabajo PHP, así que elimine los no utilizados.
Una solicitud de WordPress es pesada en PHP y DB de forma predeterminada, por lo que se cae bajo tráfico sin ajuste. El almacenamiento en caché en capas (OPcache → object cache → page cache → CDN) más PHP-FPM de tamaño correcto y una base de datos esbelta permite que un servidor único maneje órdenes de magnitud más tráfico — y lo mantiene funcionando durante los picos.