Cuando gestionas un alojamiento desde Plesk o cPanel, tarde o temprano acabas entrando en la configuración de PHP. Cambiar la versión suele ser sencillo, pero junto a ella pueden aparecer opciones como PHP-FPM, FastCGI o, dependiendo del entorno, otros modos de ejecución que no siempre resulta fácil interpretar si nunca has tenido que ocuparte demasiado de la parte del servidor. Y la elección de uno u otro importa más de lo que puede parecer.
El modo en el que se ejecuta PHP influye en cómo se gestionan los procesos, en el consumo de memoria, en el aislamiento entre webs y, por supuesto, en el rendimiento. También puede tener consecuencias en los permisos de archivos, en la forma de aplicar determinadas configuraciones o en la cantidad de peticiones simultáneas que una máquina puede atender antes de empezar a tener problemas.
Durante muchos años trabajando con proyectos alojados en todo tipo de servidores me he encontrado prácticamente de todo. Desde webs que funcionaban perfectamente en un VPS y empezaban a arrastrarse al migrarlas a un hosting compartido, hasta procesos PHP agotados, límites de memoria poco coherentes con los recursos reales de la máquina o servidores que terminaban cayéndose cuando aumentaba la carga.
Por eso merece la pena entender qué significan estas opciones. No tanto para aprender de memoria qué botón hay que marcar en Plesk o cPanel, sino para disponer de algo de criterio cuando tenemos que configurar un servidor, diagnosticar un problema o decidir si el entorno que nos proporciona un proveedor es adecuado para el proyecto que tenemos entre manos.
Qué es un modo de ejecución de PHP
Cuando un navegador solicita una página que necesita ejecutar código PHP, el servidor web tiene que hacer llegar esa petición al intérprete de PHP, esperar a que procese el código y devolver al navegador el resultado generado.
La forma en la que se resuelve esa ejecución puede variar. PHP puede estar integrado directamente en el servidor web, ejecutarse mediante procesos externos o trabajar con grupos de procesos que permanecen preparados para recibir nuevas peticiones.
Estas distintas formas de ejecutar PHP son las que terminamos encontrando en los paneles de administración bajo nombres como PHP-FPM, FastCGI o CGI.
En documentación técnica también encontrarás términos como SAPI y handler. SAPI son las siglas de Server Application Programming Interface y hace referencia a la interfaz mediante la que PHP se relaciona con el entorno que lo ejecuta. El término handler se utiliza habitualmente para referirse al mecanismo encargado de gestionar las peticiones PHP. No son conceptos estrictamente idénticos, pero en el contexto de un panel de hosting suelen aparecer alrededor de la misma decisión práctica: cómo va a ejecutarse PHP.
Dos servidores pueden utilizar exactamente la misma versión de PHP y ejecutar el mismo código, pero hacerlo de formas muy distintas. Uno puede mantener varios procesos PHP preparados para atender peticiones mientras otro puede necesitar crear nuevos procesos con mucha más frecuencia. También pueden ejecutar PHP bajo usuarios diferentes o separar de forma distinta los procesos correspondientes a cada web.
Por eso elegir PHP 8.4, 8.5 o cualquier otra versión y elegir cómo se ejecutará PHP son decisiones diferentes. La versión determina las características del lenguaje y del intérprete que tendremos disponibles. El modo de ejecución determina cómo utilizará el servidor ese intérprete para atender las peticiones.
Antes de continuar, tu servidor puede ser diferente
Antes de entrar en cada modo de ejecución conviene tener clara una cosa: no existe una configuración única que vayamos a encontrar siempre igual en Plesk o cPanel.
Las opciones disponibles dependen de la versión del panel, del sistema operativo, del servidor web, de las versiones de PHP instaladas, de los módulos disponibles y del tipo de alojamiento. También cambia mucho el escenario si estamos trabajando en un hosting compartido, un VPS o un servidor dedicado, y si tenemos acceso como usuario normal o permisos de administración.
Además, cada proveedor puede decidir qué opciones expone al cliente, cuáles limita o incluso añadir una capa propia de gestión por encima del panel. No es raro encontrarse con empresas de hosting que utilizan Plesk o cPanel internamente pero ofrecen al cliente una interfaz modificada, o que simplemente han decidido no habilitar determinadas combinaciones.
También hay que tener en cuenta la antigüedad del servidor. Los proveedores no actualizan todas sus máquinas al mismo tiempo y existen servidores perfectamente operativos que llevan años funcionando con configuraciones que hoy probablemente no elegiríamos para una instalación nueva. Por eso todavía podemos encontrarnos tecnologías que han perdido protagonismo pero que siguen formando parte de muchos entornos reales.
Esto es especialmente importante cuando trabajamos con proyectos de terceros. Puedes desarrollar una web en tu propio servidor, donde conoces los recursos disponibles y controlas la configuración, y descubrir al migrarla que el alojamiento del cliente utiliza otro servidor web, no dispone de determinados módulos o simplemente no permite configurar PHP de la misma manera.
Por eso, este artículo no pretende funcionar como una tabla de equivalencias exacta para cualquier servidor. La idea es entender qué hace cada modo de ejecución y qué implicaciones tiene. A partir de ahí, habrá situaciones en las que, como profesionales, tendremos que extrapolar lo aprendido, revisar la documentación del entorno concreto y comprobar cómo está configurada realmente la máquina.
Plesk y cPanel no exponen las mismas opciones
Aunque ambos paneles permiten gestionar PHP, no ofrecen exactamente el mismo nivel de control sobre su modo de ejecución.
En Plesk, siempre que el administrador haya habilitado varias alternativas, el usuario puede cambiar el handler PHP de un dominio directamente desde el panel. En una instalación actual sobre Linux es habitual encontrar opciones como aplicación FastCGI, aplicación FPM y aplicación FPM dedicada, que pueden seleccionarse de forma independiente para cada sitio.
Esto da al usuario cierto margen para probar o cambiar el modo de ejecución sin necesidad de solicitar al administrador una modificación global del servidor. Evidentemente, ese margen termina donde el proveedor haya decidido: solo podremos elegir entre las versiones y handlers que estén instalados y habilitados para nuestra suscripción.
En cPanel la separación es diferente. Desde MultiPHP Manager, el usuario puede gestionar principalmente la versión de PHP de cada dominio y, cuando está disponible, el uso de PHP-FPM. La elección del handler que utiliza el servidor para una determinada versión de PHP queda normalmente en un nivel de administración superior, gestionado desde WHM.
La diferencia, por tanto, no está en que Plesk permita hacer cualquier cosa y cPanel no. En ambos casos el administrador define qué tecnologías existen en la máquina y cuáles pone a disposición de las cuentas. Lo que cambia es cuánto de esa decisión queda expuesto directamente al usuario.
Si vienes de trabajar habitualmente con Plesk, esto puede resultar llamativo al entrar en cPanel. Puedes buscar un desplegable equivalente al que utilizabas para alternar entre FastCGI y FPM y no encontrarlo. No significa necesariamente que el servidor tenga menos posibilidades, sino que buena parte de esa configuración está reservada al administrador.
Principales modos de ejecución de PHP
Con esa diferencia en mente, podemos entrar ya en los modos que más sentido tiene conocer cuando trabajamos desde este tipo de paneles. Algunos los podremos seleccionar directamente y otros aparecerán sobre todo cuando heredemos servidores antiguos o necesitemos entender qué configuración hay por debajo.
PHP-FPM
PHP-FPM (PHP FastCGI Process Manager) es actualmente una de las formas más habituales de ejecutar PHP en servidores web. Parte del protocolo FastCGI, pero añade un gestor específicamente diseñado para mantener y administrar los procesos encargados de ejecutar PHP.
En lugar de arrancar el intérprete desde cero para cada petición, PHP-FPM mantiene procesos preparados para recibir trabajo. Estos se organizan en pools, que podemos entender como grupos de procesos PHP que comparten una determinada configuración y atienden las peticiones que les corresponden.
Esto permite controlar cuántos procesos pueden ejecutarse simultáneamente, cuándo se crean o destruyen y cómo se distribuye la capacidad disponible. Desde el punto de vista del desarrollador, la consecuencia más evidente es que PHP puede atender nuevas peticiones sin asumir constantemente el coste de arrancar de nuevo el intérprete.
Pero mantener procesos preparados también consume recursos. Cuantos más permitamos ejecutar simultáneamente, mayor capacidad tendremos para atender peticiones concurrentes, aunque también aumentará el consumo potencial de memoria. Este equilibrio es una de las razones por las que no basta con activar PHP-FPM y asumir que el servidor está bien configurado.
En Plesk aparece además la distinción entre FPM y FPM dedicada. Con FPM convencional, los sitios que utilizan la misma versión de PHP pueden compartir el mismo grupo de procesos. FPM dedicada utiliza procesos independientes para cada sitio, mejorando el aislamiento y evitando que el funcionamiento de una web afecte con tanta facilidad a las demás. Esa independencia tiene un coste en memoria, especialmente cuando una máquina aloja muchos proyectos.
Este tipo de decisiones son especialmente interesantes cuando administramos un VPS o un servidor con varias webs. No es lo mismo que todos los proyectos compartan determinados recursos de ejecución que poder separarlos y dimensionarlos de acuerdo con sus necesidades.
FastCGI
FastCGI nació como una evolución de CGI destinada a solucionar una de sus principales limitaciones: el coste de crear un nuevo proceso para cada petición.
Con FastCGI los procesos pueden permanecer en ejecución y atender varias solicitudes sucesivas. Esto reduce la sobrecarga respecto al CGI tradicional y permite obtener un rendimiento considerablemente mejor sin integrar PHP directamente dentro del servidor web.
Aquí aparece una confusión bastante comprensible. PHP-FPM utiliza FastCGI para comunicarse con el servidor web, pero PHP-FPM y FastCGI no son dos nombres para lo mismo.
FastCGI define un protocolo y un modelo de comunicación. PHP-FPM utiliza ese protocolo, pero añade toda una capa de gestión específica para los procesos PHP.
Dicho de otra manera, podemos ejecutar PHP mediante FastCGI sin utilizar PHP-FPM. Precisamente por eso Plesk puede mostrar ambas posibilidades en el mismo desplegable.
En Plesk, FastCGI continúa siendo uno de los handlers actuales. En Linux suele convivir con FPM, mientras que en determinados entornos Windows sigue teniendo bastante sentido por la forma en la que se integra PHP con el servidor web.
CGI
CGI (Common Gateway Interface) es bastante anterior a las alternativas que acabamos de ver y resulta útil entenderlo precisamente porque explica por qué aparecieron FastCGI y PHP-FPM.
En el modelo CGI tradicional, el servidor web lanza el programa encargado de procesar la petición, obtiene su respuesta y termina el proceso. Aplicado a PHP, esto implica asumir repetidamente el coste de arrancar el intérprete para ejecutar el script solicitado.
En una web con muy pocas peticiones puede parecer un detalle menor. Cuando empiezan a llegar muchas solicitudes, crear y destruir procesos continuamente supone una sobrecarga importante y dificulta competir en rendimiento con soluciones que mantienen procesos disponibles.
CGI no ha desaparecido. Todavía podemos encontrarlo en determinados servidores, especialmente en instalaciones antiguas o configuraciones mantenidas por compatibilidad.
Es un buen ejemplo de algo que aparecerá varias veces en este artículo: que una tecnología siga funcionando no significa que sea la opción que elegiríamos al configurar hoy un servidor desde cero.
mod_php y DSO
Durante muchos años una de las formas más habituales de ejecutar PHP con Apache fue cargar el intérprete directamente como un módulo del propio servidor web. Es lo que normalmente conocemos como mod_php.
En cPanel se ha utilizado habitualmente la denominación DSO (Dynamic Shared Object) para esta forma de ejecución.
En lugar de enviar las peticiones PHP a un servicio independiente, Apache carga PHP dentro de sus propios procesos y ejecuta directamente el código. Esto elimina determinadas capas intermedias y durante mucho tiempo ofreció una solución sencilla y con buen rendimiento.
La integración tiene también inconvenientes. Los procesos de Apache pueden cargar PHP aunque no todas las peticiones que atiendan necesiten ejecutarlo, incrementando el consumo de memoria. Además, en entornos compartidos puede complicar el aislamiento entre usuarios y la gestión de propietarios y permisos de los archivos.
Es uno de esos problemas que resultan bastante familiares cuando se trabaja con servidores antiguos: PHP crea un archivo bajo el usuario del servidor web, después intentamos modificarlo mediante FTP o desde la cuenta correspondiente y descubrimos que los propietarios no coinciden. No es raro que históricamente estos problemas terminaran solucionándose a base de permisos excesivamente abiertos, con las implicaciones de seguridad que eso conlleva.
Actualmente tiene interés sobre todo cuando tenemos que entender configuraciones heredadas. Si llegamos a una máquina que lleva años funcionando con mod_php o DSO, conviene saber qué implica antes de cambiarlo por otra alternativa únicamente porque sea más moderna.
Otros handlers que puedes encontrar por debajo de cPanel
Si trabajas exclusivamente desde cPanel, probablemente no tengas que elegir directamente entre suPHP, LSAPI, FCGId o DSO. Eso no significa que no puedan estar formando parte de la configuración del servidor.
cPanel permite al administrador definir desde WHM distintos handlers para las versiones de PHP instaladas. Para el usuario del alojamiento, lo importante no es memorizar todos ellos, sino entender que cuando PHP-FPM está desactivado existe igualmente un mecanismo por debajo encargado de ejecutar PHP y que ese mecanismo depende de cómo haya sido configurada la máquina.
Esto explica también por qué dos alojamientos con cPanel, la misma versión de PHP y aparentemente opciones similares pueden comportarse de forma diferente. El panel que ve el usuario no siempre muestra toda la arquitectura que hay detrás.
En servidores más antiguos, por ejemplo, podemos encontrarnos con suPHP, una solución que tuvo bastante presencia en hosting compartido porque permitía ejecutar PHP bajo el usuario propietario de cada cuenta, facilitando el aislamiento y evitando muchos problemas de permisos propios de mod_php.
También podemos encontrar LSAPI, especialmente en entornos relacionados con LiteSpeed o CloudLinux, o FCGId, otra implementación basada en procesos persistentes que utiliza FastCGI. Todos ellos forman parte del ecosistema que puede existir debajo de cPanel, aunque normalmente no sean decisiones que el usuario vaya alternando desde el panel como ocurre con FPM y FastCGI en Plesk.
Elegir un modo de ejecución no significa que PHP esté bien configurado
Elegir PHP-FPM, FastCGI o cualquier otro modo de ejecución es solo una parte de la configuración. El comportamiento real de una web depende también de cómo se haya dimensionado el entorno y de los recursos que tenga disponibles.
PHP-FPM es un buen ejemplo. Como hemos visto, trabaja con pools de procesos que permanecen preparados para atender peticiones. Eso mejora la eficiencia, pero obliga a decidir cuántos procesos pueden existir, cuándo se crean, cuánto tiempo permanecen disponibles y qué recursos puede consumir el conjunto.
Si permitimos demasiados procesos en una máquina con poca memoria, el servidor puede terminar intercambiando memoria con disco, degradando el rendimiento o incluso quedándose sin recursos. Si ponemos el límite demasiado bajo, puede ocurrir lo contrario: llegan más peticiones de las que los procesos disponibles pueden atender y estas empiezan a acumularse a la espera de que quede alguno libre.
En PHP-FPM, parámetros como pm.max_children determinan precisamente cuántos procesos pueden atender peticiones al mismo tiempo. No es necesario entrar aquí en toda la configuración del gestor de procesos, pero sí entender que ese valor no puede decidirse de manera aislada. Depende de la memoria disponible, de lo que consuma realmente cada proceso PHP y de cuántas aplicaciones estén compartiendo la máquina.
Algo parecido ocurre con límites como memory_limit. Podemos configurar PHP para que un proceso utilice hasta 512 MB de memoria, pero eso no significa que el servidor pueda soportar diez, veinte o cincuenta procesos consumiendo esa cantidad simultáneamente. Los límites configurados en PHP y los recursos físicos de la máquina tienen que guardar cierta coherencia.
Además, dos proyectos pueden necesitar configuraciones muy diferentes. Una web sencilla que sirve páginas cacheadas apenas mantendrá ocupados sus procesos, mientras que una tienda online o una aplicación que realiza consultas pesadas, genera documentos o espera constantemente respuestas de servicios externos puede mantenerlos trabajando durante bastante más tiempo.
Este último caso es fácil de pasar por alto. Mientras un proceso PHP espera durante varios segundos la respuesta de una API externa, sigue estando ocupado. Si empiezan a acumularse peticiones de este tipo, podemos agotar los procesos disponibles aunque el procesador de la máquina apenas parezca estar trabajando.
Por eso, cuando una web tiene problemas de rendimiento, saber que utiliza PHP-FPM aporta información, pero no da el diagnóstico. Hay que comprobar cómo está configurado, qué está haciendo la aplicación y qué capacidad real tiene la máquina.
Y esto vale también para el resto de modos de ejecución. Un sistema técnicamente más moderno no garantiza por sí mismo mejores resultados. La arquitectura importa, pero la configuración concreta y el contexto en el que se utiliza pueden importar tanto o más.
Cuando el problema no es PHP
Hay otro error bastante habitual cuando estamos depurando problemas de rendimiento que es asumir que, si una web PHP funciona mal, el problema tiene que estar en PHP. Pero por experiencia, muchas veces no es así y es importante no saltarse hacer un análisis en profundidad.
Una situación que me he encontrado en bastantes ocasiones aparece al migrar un proyecto entre servidores. La web funciona correctamente en el entorno de desarrollo o en un VPS y, después de trasladarla al alojamiento definitivo, empieza a responder lentamente, aparecen errores o directamente deja de funcionar alguna funcionalidad.
A veces la explicación está en PHP. Puede faltar una extensión, haber cambiado algún límite o utilizarse otra versión. Pero también puede ocurrir sencillamente que hayamos pasado de una máquina con recursos suficientes a un hosting compartido que no puede asumir la carga del proyecto.
El tipo de alojamiento establece límites que no siempre resultan evidentes desde el panel. Podemos disponer de un memory_limit aparentemente generoso y, sin embargo, tener restricciones adicionales de CPU, memoria física, procesos simultáneos o entrada y salida de disco impuestas por el propio proveedor.
Incluso cuando administramos un VPS, disponer teóricamente de determinados recursos no significa que cualquier configuración vaya a funcionar correctamente. Hay que repartir memoria entre el sistema operativo, el servidor web, PHP, la base de datos, los sistemas de caché y cualquier otro servicio que esté funcionando en la máquina.
También existen problemas que quedan completamente fuera de nuestro control. Un nodo de virtualización saturado, un almacenamiento con mal rendimiento o un servidor compartido en el que conviven demasiadas cuentas pueden provocar síntomas muy similares a los de una mala configuración de PHP. De hecho, distinguir cuándo el problema de una web está realmente en el hosting no siempre es tan evidente como parece.
Y ahí es donde la experiencia termina teniendo bastante peso. Si una aplicación que conoces bien empieza a comportarse de una forma extraña justo después de cambiar de proveedor o de máquina, conviene estudiar el nuevo entorno antes de empezar a modificar código o parámetros PHP sin una hipótesis clara.
Esto puede resultar especialmente frustrante cuando el soporte técnico del proveedor asegura que todo funciona correctamente porque sus métricas generales no muestran ninguna incidencia. He trabajado con alojamientos donde el problema no era lo contratado sobre el papel, sino la capacidad real que terminaba recibiendo la web.
Por supuesto, tampoco todo problema de hosting es culpa del proveedor. Una consulta SQL mal planteada, una llamada externa sin un tiempo de espera razonable o un proceso que bloquea recursos durante demasiado tiempo pueden derribar una configuración que, para el resto de proyectos alojados en esa misma máquina, funciona perfectamente.
La conclusión práctica es que el modo de ejecución de PHP debe formar parte del diagnóstico, no convertirse automáticamente en el culpable. Si queremos entender qué está pasando, tenemos que observar la aplicación y el servidor como un conjunto.
Qué modo elegir según el proyecto
Después de todo lo anterior puede resultar tentador buscar una respuesta sencilla a la pregunta de qué modo deberíamos utilizar. En la mayoría de servidores actuales, PHP-FPM será probablemente el punto de partida más razonable, pero convertir esa afirmación en una regla universal sería ignorar precisamente todo lo que hemos visto hasta ahora.
El modo adecuado depende del servidor, del tipo de proyecto, de los recursos disponibles y de cuánto control tengamos sobre la máquina. Además, en cPanel es posible que buena parte de esta decisión ni siquiera esté en manos del usuario, mientras que en Plesk podemos disponer de varias alternativas directamente desde la configuración del dominio.
Como punto de partida inicial, podemos plantear algunos escenarios habituales:
| Escenario | Punto de partida razonable | Qué vigilar |
|---|---|---|
| Web corporativa o proyecto PHP de carga moderada | PHP-FPM | No sobredimensionar procesos ni memoria |
| Tienda online | PHP-FPM | Concurrencia, consultas a base de datos, procesos disponibles y caché |
| Aplicación con mucho tráfico concurrente | PHP-FPM | Número de procesos disponibles y consumo por proceso |
| Aplicación con tareas PHP largas | PHP-FPM | Procesos ocupados durante demasiado tiempo |
| Aplicación con muchas llamadas a servicios externos | PHP-FPM | Timeouts, bloqueos y procesos retenidos esperando respuesta |
| Varias webs en un VPS | FPM con buen aislamiento entre sitios | Reparto de memoria y límites de cada pool |
| Varias webs en Plesk con necesidad de mayor aislamiento | FPM dedicada, si los recursos lo permiten | Mayor consumo de memoria |
| Hosting compartido | La mejor opción que permita el proveedor, normalmente FPM si está disponible | Límites reales de CPU, memoria, procesos y recursos compartidos |
| Servidor Windows con Plesk | FastCGI | Particularidades del servidor y de la configuración disponible |
| Servidor antiguo o heredado | Evaluar antes de cambiar | Compatibilidad, permisos y dependencias existentes |
Esta tabla debe entenderse como una orientación, no como una receta. Dos proyectos aparentemente similares pueden tener necesidades completamente distintas si uno sirve contenido sencillo y otro mantiene muchas peticiones concurrentes, ejecuta procesos costosos o depende de varios servicios externos para completar cada operación.
También conviene separar la elección del modo de ejecución de la decisión sobre dónde alojar el proyecto. No tiene demasiado sentido afinar PHP-FPM durante horas si el hosting contratado no dispone de recursos suficientes para la aplicación. Del mismo modo, contratar una máquina más potente no solucionará necesariamente un código que mantiene procesos bloqueados o consume memoria sin control.
Si administras tu propio VPS y no tienes una necesidad específica que indique lo contrario, PHP-FPM suele ser una base sensata sobre la que trabajar. A partir de ahí, el verdadero trabajo consiste en dimensionarlo de acuerdo con la aplicación y la capacidad de la máquina.
Si trabajas desde un hosting compartido, tendrás bastante menos margen. En ese caso cobra todavía más importancia conocer qué ofrece realmente el proveedor y detectar cuándo las limitaciones vienen del entorno y no de una configuración que puedas modificar desde el panel.
Y si llegas a un servidor existente que utiliza una tecnología más antigua, no daría por hecho que hay que cambiarla simplemente porque exista una alternativa más moderna. Antes merece la pena comprobar qué aplicaciones dependen de esa configuración, cómo se gestionan los permisos y qué consecuencias tendría modificarla.
Deja una respuesta