Comparación de gestores PHP: repercusiones en el rendimiento del alojamiento web

Esta comparación de controladores PHP muestra cómo mod_php, CGI, FastCGI, PHP-FPM y LSAPI Actuación influyen en tu alojamiento, desde la carga de la CPU hasta las latencias de cola. Te explico concretamente qué elección es la más adecuada para WordPress, WooCommerce y los picos de tráfico. Tiempo de carga reduce y, al mismo tiempo, ahorra recursos.

Puntos centrales

• PHP-FPM Escalable de forma más eficiente que mod_php y FastCGI.
• LSAPI ofrece los mejores valores en LiteSpeed.
• Aislamiento por usuario aumenta la seguridad.
• OPcache y Redis reducen las latencias.
• P95/P99 Muestra la experiencia real de los usuarios.

Cómo funcionan los controladores PHP

Un controlador PHP conecta el servidor web con el intérprete y controla Procesos, memoria y E/S para cada solicitud. CGI inicia un nuevo proceso para cada solicitud y vuelve a cargar las configuraciones, lo que genera una sobrecarga y Latencia Aumentado. Las variantes modernas como FastCGI, PHP-FPM o LSAPI mantienen los trabajadores disponibles de forma persistente, lo que ahorra tiempo de arranque, cambios de contexto y ciclos de CPU. OPcache permanece en la memoria, por lo que no es necesario compilar el código byte cada vez y las páginas dinámicas responden más rápido. Al mismo tiempo, la gestión de procesos decide cuántas solicitudes simultáneas pueden ejecutarse, cómo se establecen las prioridades y cómo se pueden amortiguar los picos de carga.

Comparación directa de los operadores habituales

La elección del manipulador determina la Escala, el modelo de seguridad y los requisitos de RAM de una aplicación. mod_php integra PHP en el proceso de Apache y ofrece tiempos de respuesta cortos, pero adolece de una Aislamiento entre cuentas. CGI separa claramente a los usuarios, pero consume una gran cantidad de tiempo de CPU por cada solicitud. FastCGI reduce la sobrecarga, pero sigue siendo menos eficiente que un PHP-FPM bien ajustado. LSAPI va un paso más allá cuando se utiliza LiteSpeed y estabiliza especialmente las latencias de cola en muchas conexiones simultáneas.

manipulador	Actuación	Seguridad	Requisitos de RAM	Escalabilidad	Escenario operativo
mod_php	Alta	Bajo	Bajo	Medio	Sitios pequeños, picos poco frecuentes
CGI	Bajo	Alta	Alta	Bajo	Contenidos estáticos, pruebas
FastCGI	Medio	Medio	Medio	Medio	solución provisional
PHP-FPM	Muy alta	Alta	Bajo	Alta	Alojamiento compartido, CMS
LSAPI	Más alto	Medio	Muy bajo	Muy alta	Alto tráfico, comercio electrónico

PHP-FPM en la práctica: procesos, pools, ajuste

PHP-FPM funciona con grupos de trabajadores que extraen solicitudes de una cola y, de este modo, Picos de carga amortiguar con elegancia. Establezco un grupo propio para cada sitio web, de modo que la configuración, los límites y el contexto del usuario permanecen separados y el Seguridad aumenta. En la práctica, los ajustes adaptativos como pm = dynamic u ondemand resultan rentables, ya que el número de procesos activos se adapta a la demanda. Es fundamental dimensionar correctamente pm.max_children y los límites de tiempo para que la cola no crezca y aún queden reservas de RAM. Para empezar, recomiendo comprobar los parámetros de forma estructurada; aquí explico los detalles del ajuste fino: Gestión de procesos PHP-FPM.

LSAPI y LiteSpeed: valor máximo con alta simultaneidad

LSAPI mantiene los procesos PHP en memoria y reduce los cambios de contexto, lo que permite que el contenido dinámico se HTTP/3 y QUIC se suministran con mayor fluidez. A plena carga, la latencia P95/P99 se mantiene más estable que en muchas alternativas, lo que Experiencia del usuario mejorado visiblemente. Veo regularmente más solicitudes por segundo y un TTFB más corto en las páginas de la tienda y de contenido, especialmente cuando OPcache y la caché del servidor funcionan juntos. La ventaja no solo se refleja en los valores medios, sino también en las sesiones simultáneas, las sesiones con fallos de caché y los trabajadores PHP „fríos“. Si quieres entender la diferencia de arquitectura, lee la descripción general de LiteSpeed frente a Nginx y luego decide sobre la pila.

WordPress y WooCommerce: clasificar correctamente los valores medidos

En WordPress, consigo un alto rendimiento con PHP 8.2 en FPM o LSAPI. req/s, mientras que WooCommerce genera algo menos de solicitudes por segundo debido a las sesiones, la lógica del carrito y un mayor número de accesos a la base de datos. La prueba solo resulta significativa en condiciones realistas. Tráfico mezclado con aciertos y fallos de caché. El CSS crítico, la caché de objetos y las conexiones persistentes desplazan el límite a partir del cual se producen cuellos de botella. Son especialmente útiles los TTL cortos para contenidos que cambian con frecuencia y las claves de caché diferenciadas para el idioma, el estado del usuario y el tipo de dispositivo. De este modo, la página sigue siendo rápida, aunque ofrezca contenidos personalizados.

Seguridad y aislamiento: grupos, contexto de usuario, límites

Prefiero el alojamiento multiusuario separado. piscinas por cuenta, para que los derechos, las rutas y los límites permanezcan claramente separados. mod_php comparte un contexto común, lo que Riesgo aumenta cuando un proyecto presenta lagunas. FPM o LSAPI con configuraciones por usuario reducen considerablemente esta superficie de ataque, ya que los procesos se ejecutan bajo el usuario correspondiente. A esto se suma la posibilidad de establecer diferentes opciones php.ini a nivel de proyecto sin afectar a otros sitios. Los límites de recursos, como max_execution_time y memory_limit por grupo, evitan que los valores atípicos ralenticen el servidor.

Consumo de recursos y planificación de RAM

Cada trabajador PHP ocupa, dependiendo del código, las extensiones y OPcache-Memoria que varía considerablemente en tamaño, por lo que mido la ocupación real en lugar de hacer conjeturas. Herramientas como ps, top o systemd-cgtop muestran cuánta RAM ocupan realmente los trabajadores activos y cuándo. Intercambio amenaza. A continuación, establezco pm.max_children de forma conservadora, dejo margen para la base de datos, el servidor web y los servicios de caché, y observo la latencia P95 en el pico. Si quedan reservas, aumento gradualmente el número de hijos y vuelvo a comprobarlo. De este modo, la capacidad total crece de forma controlada, sin sobrecargar el servidor.

Metodología de medición: desde TTFB hasta P99

No solo evalúo los valores medios, sino sobre todo P95– y latencias P99, porque reflejan la experiencia real bajo carga. Una pila puede funcionar con un rendimiento idéntico y, sin embargo, tener un rendimiento peor en P99 si Colas crecer. Por eso pruebo cachés fríos y calientes, mezclo solicitudes de lectura y escritura y utilizo valores de concurrencia realistas. Sin el calentamiento de OPcache, interpreto los resultados con cautela, ya que muchos sistemas se vuelven significativamente más rápidos después de unas pocas llamadas de calentamiento. Solo después de realizar pruebas representativas decido sobre los controladores, la estrategia de almacenamiento en caché y los límites del proceso.

Guía para elegir el manipulador adecuado

Para páginas pequeñas con pocos inicios de sesión, basta con mod_php o un económico FPMConfiguración, siempre que se tengan en cuenta los aspectos de seguridad. Si aumenta la simultaneidad, cambio a PHP-FPM con piscinas separadas por proyecto y activo OPcache de forma sistemática. En tiendas muy dinámicas y con muchas sesiones, prefiero LiteSpeed con LSAPI para mantener bajos los valores P95 y P99. Quienes se quedan con Apache/Nginx por motivos de precio o arquitectura, obtienen muy buenos resultados con FPM bien ajustado. En todos los casos, la medición en condiciones realistas cuenta más que las pruebas de rendimiento en un sistema vacío.

Configuración práctica: almacenamiento en caché, sesiones, límites de tiempo

Apuesto por OPcache con generosas Memoria-Asignación, para que el código byte rara vez se desplace, y traslada las sesiones, si es posible, a Redis, para evitar bloqueos de archivos. Esto reduce los tiempos de espera en inicios de sesión simultáneos y páginas personalizadas. Para los servicios externos, defino tiempos de espera y disyuntores claros para que las fallas no bloqueen toda la solicitud. A nivel de aplicación, mantengo los TTL de caché lo suficientemente cortos como para mantener la actualidad, pero lo suficientemente largos como para lograr una alta tasa de aciertos. Si te enfrentas regularmente a límites de trabajadores, aquí encontrarás una introducción: Equilibrar correctamente los trabajadores PHP.

Comparación coste-beneficio y funcionamiento

Califico el Costos un cambio a cambio de una ganancia cuantificable en latencia, rendimiento y fiabilidad. El salto de FastCGI a PHP-FPM suele aportar más que un cambio en el número de subversión de PHP, porque Proceso-Gestión y almacenamiento en caché con efecto continuo. LSAPI resulta especialmente útil cuando ya se utiliza LiteSpeed y hay muchos visitantes simultáneos. Quienes cambien la pila deben supervisar de cerca los registros y las métricas y preparar rutas de reversión. Una operación A/B planificada durante varios días proporciona los resultados más fiables.

Interacción entre servidores web: Apache-MPM, Nginx y Keep-Alive

En la práctica, no solo decide el gestor PHP, sino también el modo del servidor web. mod_php funciona con Apache en prefork-MPM, pero bloquea el uso de modelos de eventos modernos. Si desea utilizar HTTP/2, fases Keep-Alive más largas y miles de conexiones de manera eficiente, apueste por Apache. evento + PHP-FPM o Nginx/LiteSpeed como interfaz. La consecuencia: el número de trabajadores PHP necesarios no depende del número de conexiones TCP, sino del número real de al mismo tiempo Solicitudes PHP en curso. Por lo tanto, la multiplexación HTTP/2/3 reduce la sobrecarga de los encabezados en el servidor web, pero no cambia nada en cuanto a los pools PHP de dimensiones insuficientes.

Nginx suele reenviar las solicitudes a FPM a través de FastCGI. Presto atención a que sean breves. tiempo_de_lectura- y send_timeouten el proxy, ya que de lo contrario se producirán errores 502/504 en los upstreams pendientes, aunque PHP siga funcionando. En entornos Apache, limito Keep-Alive para que las conexiones inactivas prolongadas no ocupen el grupo de subprocesos. LiteSpeed abstrae gran parte de esto, pero solo aprovecha al máximo su ventaja con LSAPI.

OPcache, JIT y precarga: lo que realmente ayuda

OPcache es obligatorio. En la práctica, yo dimensiono opcache.consumo_memoria generoso (por ejemplo, 192-512 MB dependiendo de la base de código) y aumenta opcache.max_accelerated_files, para evitar desalojos. Para las compilaciones que se implementan con poca frecuencia, desactivo validar_marcas_de_tiempo o establece un valor más alto revalidar_frecuencia, para ahorrar llamadas al sistema. Precarga puede acelerar los marcos, pero despliega su efecto sobre todo con una estructura de autocarga consistente. El JIT de PHP rara vez aporta ventajas en cargas de trabajo web clásicas e incluso puede consumir RAM; solo lo activo cuando las pruebas de rendimiento en condiciones reales lo confirman.

Gestión de colas y contrapresión

La mayoría de los cuellos de botella no se producen en la CPU, sino en la cola. Si llegan más solicitudes de las que los trabajadores pueden procesar, la cola crece y la latencia P95/P99 se dispara. Me aseguro de que pm.max_hijos Lo suficientemente grande como para absorber los picos típicos, pero lo suficientemente pequeño como para mantener la reserva de RAM. pm.max_requests Lo pongo moderado (por ejemplo, 500-2000) para que las fugas de memoria no generen procesos de larga duración. El lista.atraso Debe ajustarse al backlog del servidor web, de lo contrario, el kernel interrumpirá las conexiones bajo carga. Quien mida la tasa de llegada (solicitudes por segundo) y el tiempo medio de servicio, puede evaluar con un simple cálculo de capacidad a partir de qué concurrencia se produce el cambio en la latencia.

Tiempo de espera, cargas y archivos de larga duración

Las cargas largas o las llamadas API bloquean a los trabajadores. Establezco límites claros: tiempo_de_ejecución_máximo y request_terminate_timeout En FPM, evito que las solicitudes defectuosas se ejecuten indefinidamente. A nivel de proxy, sincronizo proxy_read_timeout/fastcgi_read_timeout con los límites FPM, para que no se produzcan 504 prematuros. Transmito las cargas grandes, limito post_max_size y tamaño máximo de archivo de carga y planifica puntos finales dedicados para que el resto del tráfico no se vea afectado. Para tareas de larga duración similares a cron, traslado el trabajo a Cues o trabajos CLI, en lugar de bloquear los trabajadores frontend durante minutos.

Sesiones y bloqueo en detalle

Las sesiones PHP son, por defecto, bloqueando. Una segunda solicitud del mismo usuario espera hasta que la primera libere la sesión, lo que resulta fatal para WooCommerce si se ejecutan llamadas Ajax en paralelo. Finalizo las operaciones de escritura de la sesión de forma anticipada con session_write_close(), tan pronto como ya no sean necesarias más mutaciones. Con Redis como backend de sesión, la latencia de E/S disminuye, pero las reglas de bloqueo siguen siendo importantes. Detrás de los equilibradores de carga, decido conscientemente entre sesiones persistentes (simples, menos escalables) y patrones sin estado con caché de objetos, para que la escalabilidad horizontal funcione correctamente.

Supervisión y resolución de problemas

Sin telemetría, el ajuste es como volar a ciegas. Activo el estado FPM y los registros lentos por grupo para ver los cuellos de botella e identificar las consultas que llaman la atención.

; por pool pm.status_path = /status ping.path = /ping ping.response = pong request_slowlog_timeout = 3s slowlog = /var/log/php-fpm/www-slow.log pm.max_requests = 1000

Si se produce un error 502/504, lo primero que compruebo es: ¿está llena la cola FPM? ¿Hay robo de CPU o intercambio? ¿El tiempo de espera del servidor web se ajusta a los límites FPM? Echa un vistazo a smaps por trabajador muestra la ocupación RSS real, mientras que netstat/ss Detecta los desbordamientos de backlog. Para OPcache, observo la tasa de aciertos y el número de revalidaciones para evitar expulsiones.

Contenedores, sockets y límites de recursos

En los contenedores suelo utilizar TCP en lugar de sockets Unix entre el servidor web y FPM, para evitar límites de espacio de nombres y facilitar el equilibrio de carga. Es importante que sean consistentes. cgroup-Límites: si el contenedor solo tiene 1-2 GB de RAM, pm.max_children debe ser proporcionalmente menor, de lo contrario se activará el OOM-Killer. Las cuotas de CPU influyen mucho en el tiempo de respuesta; planifico el margen y verifico la latencia P95 por debajo del límite. Los temas NUMA y Core Affinity son relevantes con cargas muy altas, mientras que LSAPI optimiza gran parte de ello internamente en las configuraciones LiteSpeed.

Múltiples versiones de PHP y extensiones

Muchos hosts ejecutan varias versiones de PHP en paralelo. Aíslo los grupos por versión y mantengo Extensiones Delgado. Cada módulo adicional aumenta la RAM por trabajador y puede prolongar el tiempo de inicio. Elimino sistemáticamente las extensiones que no se utilizan; esto suele aportar más que un pequeño aumento de pm.max_children. Durante la actualización, planifico breves fases de calentamiento para OPcache, de modo que, tras la implementación, no todos los usuarios experimenten arranques en frío al mismo tiempo.

Dieta RAM y planificación realista de la capacidad

En lugar de valores generales, calculo los requisitos medios y máximos de RAM por trabajador con tráfico en tiempo real. De ahí deduzco lo siguiente: (RAM disponible – sistema/base de datos/cachés) / RAM por trabajador = máximo pm.max_children razonable. Además, mantengo una reserva de 15-25 % para picos, caché del kernel y picos imprevistos. Si la aplicación infla la memoria de forma esporádica, reduzco el límite o acorto pm.max_requests para reciclar los procesos con más frecuencia.

Estrategia de prueba: carga reproducible y patrones reales

Utilizo perfiles de prueba que mezclan cachés fríos y calientes, combinan GET/POST y aumentan gradualmente la concurrencia. Importante: solo con OPcache activo y tiempos de reflexión realistas puedo ver si el sistema se mantiene estable bajo el comportamiento de uso. Una aceleración gradual durante varios minutos evita picos artificiales al inicio. La evaluación se centra en TTFB y P95/P99, no solo en el RTT medio o en req/s puros.

Errores típicos en la práctica

• Muchos 504 por debajo del pico: cola FPM llena, backlog demasiado pequeño, tiempos de espera en el proxy más cortos que en FPM.
• Tartamudeo en las implementaciones: desplazamientos OPcache, falta de calentamiento, opcache.memory_consumption demasiado pequeño.
• Buenos valores medios, malos P99: demasiados procesos de larga duración (E/S, API externas), falta de interrupción de circuito.
• CPU alta, req/s baja: bloqueos de sesión o consultas de bases de datos no almacenadas en caché que limitan la serie.

Seguridad operativa y reversión

Cada cambio en el controlador o en los parámetros del grupo lo ejecuto con Banderas de características o por etapas. Mantengo un ojo en los registros de errores y lentitud, P95 y la tasa de error, y defino una restauración clara en caso de que las métricas se desequilibren. Un segundo grupo con la misma versión, pero con parámetros diferentes, permite un cambio rápido entre A y B sin tiempo de inactividad. Bajo plena carga, es mejor una reducción breve y automática de la concurrencia (contrapresión) que iniciar nuevos trabajadores de forma incontrolada.

Brevemente resumido

Para sitios dinámicos con muchos usuarios simultáneos, prefiero LSAPI en LiteSpeed, mientras que PHP-FPM en Apache o Nginx ofrece el mejor Todoterreno mod_php sigue siendo un caso especial para proyectos muy sencillos sin un aislamiento estricto. Lo decisivo son las pruebas realistas con OPcache caliente, límites de pool razonables y un almacenamiento en caché limpio. Quien reduce las latencias de forma fiable, mide P95/P99 y reacciona primero a los problemas de cola en lugar de a los valores medios. De este modo, una aplicación alcanza respuestas notablemente más rápidas y más reservas para el tráfico pico.