¿Sientes que tu web podría ir más rápido? ¿Has instalado el último tema, optimizado las imágenes y puesto un CDN, pero la cosa sigue sin volar? A veces, el verdadero tesoro del rendimiento no está en el frontend, sino en las tripas del servidor. Y ahí, amigo mío, es donde brilla PHP-FPM.
Si usas un stack moderno con Nginx, lo más seguro es que estés usando PHP-FPM para gestionar las peticiones PHP. Pero, ¿lo tienes bien configurado? Por defecto, viene con unos valores bastante conservadores que no le sacan todo el jugo a tu máquina.
En esta guía para 2025, vamos a sumergirnos en los archivos de configuración para optimizar PHP-FPM y darle a tu web la potencia que se merece. ¡Abróchate el cinturón!
¿Qué es PHP-FPM y por qué es clave para tu web?
Antes de tocar nada, entendamos qué es esto. PHP-FPM (FastCGI Process Manager) es, como su nombre indica, un gestor de procesos para PHP. Antiguamente, con Apache, se usaba mod_php, que cargaba el intérprete de PHP dentro del propio proceso de Apache. Era simple, pero consumía una barbaridad de memoria.
PHP-FPM es mucho más listo. Funciona como un servicio independiente. El servidor web (como Nginx) recibe una petición y, si es para un archivo .php, se la pasa a PHP-FPM. Este gestor tiene un «ejército» de procesos PHP listos para trabajar. Esta separación es lo que nos da flexibilidad y un rendimiento brutal.
La clave es que podemos controlar con precisión cómo se comporta ese «ejército» de procesos: cuántos son, cómo se crean, cuándo mueren… Y ahí es donde empieza la magia de la optimización.
El Dúo Dinámico: www.conf y php.ini
Para tunear nuestro PHP, vamos a tener que editar principalmente dos archivos:
- El archivo de configuración del pool de FPM: Normalmente lo encontrarás en rutas como
/etc/php/8.3/fpm/pool.d/www.conf. Este archivo controla el gestor de procesos. Aquí definimos cuántos «trabajadores» PHP tendremos, cómo se gestionan, etc. - El archivo
php.ini: El clásico. Lo hallarás en/etc/php/8.3/fpm/php.ini. Este archivo controla el comportamiento del propio PHP. Aquí se definen los límites de memoria, los tiempos de ejecución, la configuración de OPcache y mucho más.
Es crucial entender la diferencia: www.conf gestiona los procesos, php.ini configura lo que hace cada uno de esos procesos. Para conseguir las mejores configuraciones php-fpm, necesitamos tocar ambos.
Manos a la Obra: Optimizando el Pool de www.conf
Aquí es donde separamos a los profesionales de los aficionados. Una buena configuración aquí puede marcar la diferencia entre un servidor que aguanta miles de visitas simultáneas y uno que se cae con un pico de tráfico.
El Process Manager (pm): static, dynamic o ondemand
Esta es la primera y más importante decisión. La directiva pm define cómo se gestionarán los procesos hijos (los workers).
pm = dynamic: Es el valor por defecto y el más equilibrado. PHP-FPM mantiene un número mínimo de procesos listos y crea más (hasta un máximo) si aumenta la demanda. Cuando la demanda baja, mata los procesos sobrantes. Es la opción recomendada para la mayoría de los casos, desde sitios con tráfico medio hasta alto.pm = static: Aquí le dices a PHP-FPM: «quiero que tengas exactamente este número de procesos activos, ni uno más ni uno menos». Es ideal para servidores con muchísima RAM y un tráfico muy alto y constante, ya que elimina la sobrecarga de crear y destruir procesos. Si no estás seguro, no empieces por aquí.pm = ondemand: Los procesos solo se crean cuando llega una petición. Es perfecto para entornos de desarrollo o servidores con muy poco tráfico y muchos sitios diferentes, ya que ahorra memoria cuando no hay visitas. El inconveniente es una pequeña latencia en la primera petición, mientras se «despierta» el proceso.
Recomendación para 2025: Empieza con pm = dynamic. Es el más flexible y seguro.
Ajustando los Workers en pm.dynamic
Si has elegido dynamic, estas son las directivas que te cambiarán la vida:
pm.max_children: El número máximo de procesos hijos que se crearán. Esta es la directiva más crítica. Si te pasas, agotarás la RAM del servidor y empezará a usar swap, matando el rendimiento. Si te quedas corto, empezarás a tener errores 502 (Bad Gateway) porque no hay suficientes workers para atender las peticiones.- ¿Cómo calcularlo? Un buen punto de partida es:
pm.max_children = (Total RAM - RAM del OS/BBDD) / Consumo medio por proceso PHP. Para saber el consumo medio, puedes usar comandos comops_memmientras la web está bajo carga. Un valor seguro para empezar en un servidor con 2GB de RAM podría ser entre 15 y 25, dependiendo de tu aplicación (WordPress con muchos plugins consume más que un Laravel ligero).
- ¿Cómo calcularlo? Un buen punto de partida es:
pm.start_servers: El número de procesos que se inician cuando arranca FPM. Un buen valor es(pm.min_spare_servers + pm.max_spare_servers) / 2.pm.min_spare_servers: El número mínimo de procesos «en el banquillo», listos para entrar en acción. Si el número de procesos inactivos cae por debajo de este, se crearán nuevos. Un buen punto de partida es el 25% depm.max_children.pm.max_spare_servers: El número máximo de procesos «en el banquillo». Si hay más de este número, se empezarán a matar los sobrantes para liberar memoria. Un buen valor es en torno al 75% depm.max_children.
Con estos cuatro valores bien afinados, habrás dado un paso de gigante para optimizar php-fpm.
Evitando Memory Leaks: pm.max_requests
Esta directiva es oro puro, sobre todo si trabajas con aplicaciones como WordPress o Moodle, donde algunos plugins pueden tener fugas de memoria (memory leaks).
pm.max_requests = 500
Esto le dice a cada proceso hijo que, después de atender 500 peticiones, se reinicie automáticamente. El proceso se cierra y se crea uno nuevo, completamente limpio. Esto libera cualquier memoria que se haya podido quedar «atrapada» por un código deficiente y mantiene el sistema sano a largo plazo. Un valor entre 200 y 1000 es lo habitual.
La Guía Definitiva para Optimizar php.ini
Ya tenemos a nuestro ejército de workers listo. Ahora toca darles las herramientas y los límites adecuados. Para ello, necesitamos optimizar php.ini. ¡Vamos a ver las directivas clave!
memory_limit
El clásico. Define la cantidad máxima de memoria que un script PHP puede consumir.
memory_limit = 256M
El valor por defecto suele ser 128M. Para aplicaciones modernas como WordPress con WooCommerce o un CMS complejo, 256M es un punto de partida mucho más realista. Nunca lo pongas en -1 (ilimitado) en un entorno de producción, es una receta para el desastre. Lo ideal es monitorizar tu aplicación y ajustarlo al valor que necesite, con un pequeño margen.
max_execution_time y max_input_time
max_execution_time = 60
max_input_time = 60
La primera define el tiempo máximo en segundos que un script puede tardar en ejecutarse. La segunda, el tiempo máximo que puede tardar en procesar los datos de entrada (como un formulario).
El valor por defecto de 30 segundos a menudo se queda corto para tareas de importación o procesos de fondo. Subirlo a 60 es una medida segura. Si tienes scripts que sabes que tardan mucho más (por ejemplo, un generador de informes), puedes aumentar este valor temporalmente dentro del propio script.
OPcache: La Joya de la Corona del Rendimiento
Si solo pudieras hacer una cosa para optimizar php.ini, sería configurar correctamente OPcache. OPcache guarda el código PHP precompilado en memoria compartida, evitando que PHP tenga que leer y compilar los mismos archivos una y otra vez en cada petición. La ganancia de rendimiento es simplemente espectacular.
Asegúrate de que está activado y ajusta estos valores en tu php.ini:
ini
; Activa OPcache
opcache.enable=1
; Activa la CLI por si tienes workers o cronjobs por consola
opcache.enable_cli=1
; La cantidad de RAM para OPcache. 128MB es un buen inicio para una web media.
opcache.memory_consumption=128
; Memoria para las "cadenas internas" de PHP.
opcache.interned_strings_buffer=16
; El número máximo de scripts que puede cachear. Súbelo si tienes una app muy grande.
opcache.max_accelerated_files=10000
; Con qué frecuencia (en segundos) revisa si los archivos han cambiado.
; En producción, puedes poner un valor alto (ej. 60) o incluso 0 (nunca) si tu despliegue limpia la caché.
opcache.revalidate_freq=2
; Acelera aún más guardando los comentarios del docblock
opcache.save_comments=1
Puedes encontrar la documentación oficial completa de OPcache en la web de PHP, que es una fuente de información inmejorable.
upload_max_filesize y post_max_size
¿Alguna vez te ha salido un error al intentar subir un archivo grande a WordPress? Es por esto.
upload_max_filesize = 64M
post_max_size = 64M
upload_max_filesize limita el tamaño del archivo subido. post_max_size limita el tamaño total de la petición POST (que incluye el archivo y otros datos del formulario). Es importante que post_max_size sea siempre igual o mayor que upload_max_filesize.
Trucos Extra y Buenas Prácticas para 2025
Ya tienes las mejores configuraciones php-fpm casi listas. Aquí van unos últimos consejos:
- Activa el slow log: En
www.conf, descomenta y ajustarequest_slowlog_timeout = 5syslowlog = /var/log/php/php-fpm-slow.log. Esto creará un registro de todos los scripts que tarden más de 5 segundos en ejecutarse. Es una mina de oro para encontrar cuellos de botella en tu código. - Monitoriza el estado: Puedes activar la página de estado de FPM (
pm.status_path = /status) para ver en tiempo real cuántos procesos están activos, inactivos, etc. ¡Pero ojo! Asegúrate de proteger esta URL para que solo tú (o tu IP) puedas acceder. - Seguridad básica: En
php.ini, asegúrate de tenerexpose_php = Off. No le da ninguna ventaja de rendimiento, pero evita que el mundo sepa qué versión de PHP estás usando, un pequeño pero importante paso de seguridad.
Conclusión: Mide, Ajusta y Repite
Optimizar PHP-FPM no es una ciencia exacta, es un arte que depende de tu aplicación, tu tráfico y los recursos de tu servidor. La clave es no aplicar estos valores a ciegas.
Empieza con los valores recomendados, usa herramientas de monitorización (como New Relic, Datadog o simplemente htop y los logs) para ver cómo se comporta tu servidor bajo carga, y ajusta poco a poco.
Con esta guía y un poco de paciencia, pasarás de una configuración genérica a un sistema finamente ajustado, capaz de ofrecer una experiencia de usuario rápida y fluida. Ahora te toca a ti darle caña y optimizar php-fpm para que tu proyecto vuele en 2025.
Preguntas Frecuentes
Q: ¿Qué pasa si configuro un `pm.max_children` demasiado alto o demasiado bajo?
A: Si pones un valor demasiado alto, agotarás la memoria RAM del servidor, lo que provocará que el sistema use el disco como memoria (swap) y se ralentice drásticamente hasta colapsar. Si lo pones demasiado bajo, el servidor no podrá gestionar los picos de tráfico, y los usuarios recibirán errores 502 (Bad Gateway) porque no hay suficientes procesos PHP disponibles para atender sus peticiones.
Q: ¿Cuándo debería usar `pm = static` en lugar de `dynamic`?
A: Usa `pm = static` únicamente si tienes un servidor con mucha memoria RAM y un tráfico muy alto y constante. Al mantener un número fijo de procesos siempre activos, eliminas la pequeña sobrecarga de crearlos y destruirlos. Para la inmensa mayoría de los casos, `pm = dynamic` es superior porque se adapta a la demanda, ahorrando recursos en momentos de bajo tráfico y escalando cuando es necesario.
Q: ¿Por qué es importante configurar OPcache si ya he optimizado los workers de FPM?
A: Porque resuelven problemas diferentes. Optimizar los workers de FPM (en `www.conf`) asegura que tienes la cantidad correcta de procesos para gestionar el tráfico sin agotar los recursos del servidor. En cambio, configurar OPcache (en `php.ini`) hace que cada uno de esos procesos trabaje mucho más rápido, ya que guarda el código PHP precompilado en memoria y evita tener que leer y compilar los archivos en cada petición. Ambos son cruciales para un rendimiento máximo.
Deja una respuesta