Optimización PHP-FPM en Nginx: Guía de Alto Rendimiento

📅 Publicado el 19 de septiembre, 2026 · Por Equipo RedServicio

¿Qué es la optimización PHP-FPM y por qué importa en Nginx?

Optimizar PHP-FPM es, básicamente, ajustar la configuración del FastCGI Process Manager para que tu servidor atienda cuantas más peticiones mejor, con la menor latencia posible y sin atascharse. Nginx, a diferencia de Apache con mod_php, no ejecuta PHP él mismo: delega todo a procesos externos a través del protocolo FastCGI. Y ahí está la trampa. Un PHP-FPM mal calibrado es la causa más habitual de errores 502 Bad Gateway y de esa lentitud que aparece justo cuando el tráfico se dispara.

La buena noticia: con unas pocas directivas bien calculadas puedes multiplicar la capacidad del servidor sin gastar un euro en más hardware. Vamos al grano.

Cálculo de procesos: pm.max_children y el modo de gestión

Si solo puedes tocar un parámetro, que sea pm.max_children. Define cuántos procesos hijos pueden atender peticiones a la vez. Su valor depende del modo de gestión que elijas:

• pm = static: número fijo de procesos. Para servidores dedicados con memoria estable y tráfico predecible, funciona de maravilla.
• pm = dynamic: los procesos crecen y se reducen según la demanda. La opción sensata en un VPS con carga variable.
• pm = ondemand: no se crea nada hasta que llega una petición. Útil cuando el tráfico es muy esporádico o tienes varios sitios conviviendo en la misma máquina.

Cómo calcular pm.max_children correctamente

La fórmula es sencilla:

Para medir el consumo medio por proceso, este comando te lo da en un segundo:

• ps --no-headers -o "rss,cmd" -C php-fpm8.2 | awk '{ sum+=$1 } END { printf "%d MB\n", sum/NR/1024 }'

¿Y una configuración dinámica razonable en un VPS de 4 GB? Algo así:

• pm = dynamic
• pm.max_children = 40
• pm.start_servers = 8
• pm.min_spare_servers = 4
• pm.max_spare_servers = 12
• pm.max_requests = 500 (recicla procesos y previene fugas de memoria)

Ajustes de Nginx para acompañar a PHP-FPM

No vale afinar solo un lado. Nginx también necesita su puesta a punto, o acabará siendo él el cuello de botella. Las directivas clave, en nginx.conf:

• worker_processes auto; — un worker por núcleo de CPU.
• worker_connections 2048; — conexiones simultáneas por worker.
• keepalive_timeout 30; — reutiliza las conexiones del cliente.
• fastcgi_buffers 16 16k; y fastcgi_buffer_size 32k; — evitan escrituras temporales a disco cuando la respuesta PHP es grande.

Conexión por socket Unix en lugar de TCP

Si Nginx y PHP-FPM viven en la misma máquina, usa un socket Unix. Gana a TCP (127.0.0.1:9000) en latencia, y no es poco:

• listen = /run/php/php8.2-fpm.sock en el pool de PHP-FPM.
• fastcgi_pass unix:/run/php/php8.2-fpm.sock; en Nginx.
• Sube listen.backlog = 511 o más si esperas picos de tráfico.

Timeouts: equilibrio entre estabilidad y experiencia

Los tiempos de espera mal puestos acaban en errores 504 o procesos zombis deambulando por el sistema. Valores que funcionan:

• request_terminate_timeout = 60s (PHP-FPM): mata los scripts colgados.
• fastcgi_read_timeout 60; (Nginx): debe ser coherente con el anterior.
• max_execution_time = 55 (php.ini): un pelín por debajo de los otros, para que PHP termine de forma controlada.

OpCache y JIT: el complemento imprescindible

Sin OpCache, PHP recompila cada script en cada petición. Un desperdicio de CPU difícil de justificar. Configuración base para php.ini:

• opcache.enable = 1
• opcache.memory_consumption = 256
• opcache.max_accelerated_files = 20000
• opcache.validate_timestamps = 1 con revalidate_freq = 2 (en producción muy exigente, quizá te compense desactivar la validación y limpiar caché en cada despliegue).

Y desde PHP 8, el JIT puede sumar en cargas de CPU intensiva:

• opcache.jit = tracing
• opcache.jit_buffer_size = 128M

Monitorización: cómo saber si tu configuración funciona

Optimizar a ciegas no sirve de nada. De verdad. Habilita pm.status_path = /status en tu pool y vigila métricas como listen queue (si es mayor que 0, te faltan procesos), max children reached (saturación histórica) y el uso de memoria por proceso. Complementa con htop, New Relic o la PHP-FPM status page, esta última protegida por IP, por favor.

Preguntas frecuentes

Conclusión

La optimización PHP-FPM no tiene ningún secreto místico. Mide el consumo real de tus procesos, calcula pm.max_children con datos (no a ojo), alinea los timeouts entre Nginx y PHP-FPM, usa sockets Unix y activa OpCache. Con eso documentado y monitorizado, tu servidor absorberá los picos de tráfico sin que los tiempos de respuesta se resientan.

Un último apunte: aplica los cambios de forma incremental y compara las métricas de estado antes y después de cada modificación. Y si prefieres no complicarte con la administración del servidor, en RedServicio.net ofrecemos hosting de calidad con soporte 24/7, donde nuestro equipo técnico puede ayudarte a afinar tu entorno PHP-FPM y Nginx para sacar el máximo rendimiento a tu web.