Comparación de gestores PHP: CGI, FPM y LSAPI en alojamiento

Comparación de manejadores PHP muestra claramente cómo CGI, PHP-FPM y LSAPI controlan la ejecución de scripts PHP y, por tanto, caracterizan la latencia, el aislamiento y los requisitos de RAM en el alojamiento. Explico las diferencias de forma práctica, las clasifico según las cargas de trabajo y doy recomendaciones para su selección y configuración en el funcionamiento diario.

Puntos centrales

• ActuaciónLSAPI lidera en latencias de cola, PHP-FPM ofrece tiempos de respuesta muy constantes.
• SeguridadCGI separa estrictamente, PHP-FPM aísla con pools, LSAPI encapsula por usuario.
• RecursosLSAPI ahorra RAM, PHP-FPM sigue siendo eficiente, CGI genera sobrecarga.
• CompatibilidadPHP-FPM se adapta a Apache/Nginx, LSAPI brilla con LiteSpeed.
• PrácticaPara CMS y tiendas utilizo sobre todo PHP-FPM; mucho tráfico se beneficia a menudo de LSAPI.

Conceptos básicos de los manejadores PHP

Un manejador PHP conecta el servidor web con el servidor Intérprete PHP. CGI inicia un nuevo proceso para cada petición y consigue así una separación muy limpia entre cuentas. Esta separación cuesta tiempo porque cada petición recarga las extensiones y la configuración. PHP-FPM mantiene los trabajadores persistentes y distribuye las peticiones a pools, lo que reduce los costes de arranque y mantiene baja la latencia. LSAPI se integra profundamente con LiteSpeed y utiliza procesos muy ligeros y de larga duración para Alta eficacia.

Mod_php integra PHP directamente en el servidor web, pero el aislamiento es débil. Prefiero los manejadores modernos porque minimizan las fuentes de error y mantienen la plataforma más estable bajo carga. Si aloja muchos usuarios en un sistema, se beneficiará claramente de la separación de Contextos de usuario. Aquí es precisamente donde FPM pools y LSAPI entran en juego. CGI sigue siendo una opción segura pero lenta para sitios muy pequeños y escenarios de prueba especiales.

Cuadro comparativo: puntos fuertes y escenarios de aplicación

La siguiente tabla resume las características principales y las asigna a cargas de trabajo típicas. Yo la utilizo como ayuda para tomar decisiones rápidas sobre alojamiento php-configuraciones con CMS, tiendas o API. Tenga en cuenta que el rendimiento real también depende del almacenamiento en caché, el almacenamiento y el perfil de red. No obstante, la visión general proporciona un punto de partida sólido para una selección inicial. A continuación, afino la configuración basándome en perfiles de carga específicos y Valores medidos.

manipulador	Actuación	Seguridad	Consumo de RAM	Escalabilidad	Adecuado para
CGI	Bajo	Muy alta	Alta	Bajo	Pruebas, páginas estáticas o de acceso poco frecuente
PHP-FPM	Muy alta	Alta	Bajo	Alta	Alojamiento compartido, CMS, API
LSAPI	Más alto	Media a alta (por usuario)	Muy bajo	Muy alta	Alto tráfico, comercio electrónico, concurrencia

CGI puntúa con Separación, pero sufre de costes de inicio de proceso. PHP-FPM ofrece la mejor relación entre latencia, rendimiento y aislamiento en sistemas con Apache o Nginx. LSAPI ofrece latencias de cola muy bajas con alta competencia en stacks LiteSpeed. Si no utilizas un servidor LiteSpeed, FPM ofrece el soporte más amplio. Para sitios muy pequeños, me quedo con configuraciones simples; para proyectos en crecimiento, cambio a FPM o LSAPI.

Rendimiento bajo carga: latencia y caudal

Entre la creciente competencia, las latencias P95/P99 y el Estabilidad del rendimiento. LSAPI soporta las cargas más altas con tiempos de respuesta sorprendentemente consistentes. PHP-FPM le sigue de cerca y reacciona muy bien al ajuste del pool, por ejemplo con números de proceso dinámicos. CGI pierde notablemente velocidad tan pronto como llegan muchas peticiones cortas. Para mediciones más detalladas, por favor consulte mi Comparación de resultados, que cubre las cargas de trabajo típicas de CMS y tiendas.

Suelo combinar FPM o LSAPI con OPcache, para que el código de bytes no se genere de nuevo constantemente. Además, las cachés de proxy inverso reducen el número de visitas a PHP para contenidos recurrentes. Una cola de trabajo merece la pena para tareas de computación intensiva, de forma que las peticiones del frontend sigan siendo rápidas. Si desea interceptar picos esporádicos, utilice escalado de ráfagas de corta duración mediante trabajadores FPM adicionales. Esto mantiene las latencias de cola dentro de los límites y el Tiempos de respuesta coherente.

Seguridad y aislamiento en el alojamiento compartido

Lo que cuenta en los entornos multiusuario Aislamiento al menos tanto como la velocidad. CGI logra una separación muy limpia a través de procesos por petición, pero con mucha sobrecarga. PHP-FPM aísla por pool y permite límites duros para memoria, tiempo de ejecución y número de procesos. LSAPI también asigna procesos a cuentas, pero está ligado a la pila LiteSpeed en detalle. Si quieres categorizar los riesgos, lo mejor es que leas mi artículo sobre Riesgo compartido con FPM y establece límites claros.

Establecí una cuenta separada para cada cuenta. piscina con su propio UID/GID y derechos restrictivos. Esto limita el radio de posibles ataques y evita que los scripts defectuosos vean datos externos. Esto incluye límites de memoria, peticiones máximas por trabajador y tiempos de espera. Las actualizaciones periódicas y los permisos de archivos seguros completan el concepto. Minimizo los scripts de administración que están disponibles abiertamente en la red o los protejo con Aut.

Consumo de recursos y gestión de RAM

La RAM suele determinar Costos y densidad por servidor. LSAPI puntúa aquí con una huella muy pequeña por proceso y cambios de contexto económicos. PHP-FPM también sigue siendo eficiente si creo pools dinámicamente y dimensiono los límites adecuadamente. CGI desperdicia memoria debido a la frecuente recarga de extensiones y por lo tanto es poco adecuado para proyectos dinámicos. Si usted aloja muchas cuentas, FPM o LSAPI le da significativamente más reservas por nodo y mantiene la Costes totales planificable.

Mido regularmente los picos de RAM y observo su distribución a lo largo del día. Los picos indican un número demasiado bajo de trabajadores o estrategias de caché desfavorables. Reduzco la demanda con un dimensionamiento más fino del pool y un ajuste específico de OPcache. De este modo se reducen los riesgos de intercambio y se evitan los valores atípicos de latencia impredecibles. En los hosts superpoblados, desplazo los Sitios en sus propios nodos antes de que se resienta el rendimiento global.

Compatibilidad con Apache, Nginx y LiteSpeed

La elección del servidor web guía la decisión en el manipulador. PHP-FPM funciona excelentemente detrás de Nginx y puede conectarse limpiamente a Apache vía proxy. En entornos Apache, recomiendo mpm_event, ajuste keep-alive y una configuración proxy estable. LSAPI despliega todo su potencial con LiteSpeed y lee archivos .htaccess de forma eficiente. Los que ya usan LiteSpeed a menudo obtienen la última pizca de rendimiento con LSAPI. Actuación fuera.

Para el contenido estático, utilizo Nginx o LiteSpeed directamente desde la caché del servidor web. PHP sólo procesa lo que debe permanecer dinámico. Esta separación reduce la carga del gestor y ahorra tiempo de CPU. Como efecto secundario, la consistencia TTFB aumenta con las peticiones de páginas recurrentes. Esto mantiene la capacidad de respuesta de los frontends, incluso cuando Backends están bajo presión.

Buenas prácticas para los pools PHP FPM

Empiezo con un conservador Disposición de la piscina por sitio y mido los picos reales. Luego ajusto pm, pm.max_children, pm.start_servers y pm.max_requests. Los pools demasiado pequeños hacen esperar a las peticiones, los pools demasiado grandes consumen RAM y generan cambios de contexto. Para WordPress, WooCommerce o TYPO3, suelo elegir dinámico u ondemand y regular bien los límites. Los detalles sobre pm.max_children se pueden encontrar en mi guía pm.max_hijos resumido.

Establezco límites como memory_limit y max_execution_time por pool. request_terminate_timeout protege de los procesos colgados que, de otro modo, se acumularían. max_input_vars y upload_max_filesize están sensiblemente asegurados, dependiendo del proyecto. Esto mantiene los pools controlable y el anfitrión es estable.

Caché y OPcache en la práctica

Para mí, OPcache forma parte de cada Instalación de PHP. Lo activo, compruebo el tamaño y controlo el porcentaje de aciertos. Para muchos despliegues, configuro file_cache_only y ajusto revalidate_freq para que los despliegues surtan efecto rápidamente. También utilizo cachés de proxy inverso y plugins de caché de página en CMS para reducir la tasa de aciertos de PHP. Cuantas menos peticiones terminen en PHP, mejor será la escalabilidad. todo.

Quienes utilizan intensivamente las sesiones del lado del servidor suelen beneficiarse de Redis. Regulo los TTL y gestiono estrictamente los límites de memoria. Para la caché de página completa, tengo en cuenta las claves de caché y las estrategias de invalidación para que las tiendas entreguen correctamente después de los cambios de precios o existencias. Un plan de caché claro ahorra CPU, RAM y tiempo. La interacción de OPcache, proxy cache y Caché de aplicaciones determina en última instancia la velocidad percibida.

Matriz de decisión: ¿Qué gestor se adapta a cada proyecto?

Los sitios pequeños con poco tráfico funcionan de forma segura con PHP-FPM y límites conservadores. Los entornos de prueba puros o los requisitos de cumplimiento especiales pueden hacer que CGI sea útil, a pesar de la pérdida de velocidad. Las tiendas con mucho tráfico y API muy competitivas suelen beneficiarse de LSAPI en LiteSpeed. Si necesita la máxima compatibilidad y flexibilidad, puede confiar en FPM. Para alojar php con WordPress o WooCommerce, prefiero FPM por su versatilidad. Todoterreno antes.

Nunca tomo una decisión basándome únicamente en una referencia. En su lugar, mido la mezcla real de visitas estáticas, páginas dinámicas y llamadas a la API. El tiempo medio de script y la proporción de visitas a la caché también influyen en la elección. También tengo en cuenta los hábitos de administración, como los despliegues frecuentes o los procesos de compilación. La mejor solución sigue siendo la que funciona en condiciones reales. Condiciones estable y rápido.

Costes, licencia y funcionamiento: ¿qué compensa?

Desde el punto de vista de los costes puros FPM atractivo, ya que no requiere licencias adicionales. LSAPI puede reducir los costes operativos por sitio gracias a una mayor densidad y menores latencias, pero requiere licencias LiteSpeed en euros. Para muchos clientes de pago suele ser rentable, pero no suele serlo para proyectos de aficionados. CGI causa costes indirectos por la utilización ineficiente de los recursos y los tiempos de respuesta más largos. Por lo tanto, calculo la operación global y ahorro donde tiene sentido. calidad no se ponga en peligro.

La capacidad de planificación sigue siendo importante. Un host con demasiadas reservas ahorra dinero a corto plazo, pero lo paga con tiempos de inactividad y usuarios insatisfechos. Las modernas herramientas de observabilidad ayudan a reconocer los cuellos de botella en una fase temprana. Quienes añaden capacidad con regularidad mantienen estables las latencias y alivian la carga del servicio de asistencia. Al final, la solución que conserva recursos y minimiza Tiempo de actividad alto.

Versiones multi-PHP, rollouts y tiempo de inactividad cero

En la vida cotidiana, a menudo manejo varios Versiones PHP en paralelo. Con FPM, esto se consigue limpiamente mediante pools separados y sockets separados para cada versión. Esto me permite migrar los sitios paso a paso sin interrumpir el sistema general. Planifico actualizaciones continuas: primero la puesta en marcha, luego un pequeño grupo de producción y después el resto. Recargas con gracia (FPM: recargar en lugar de reiniciar) evitan los arranques bruscos y mantienen las conexiones abiertas. Con LSAPI, utilizo mecanismos análogos en la pila LiteSpeed para precalentar a los trabajadores y minimizar el efecto de arranque en frío.

Para las implantaciones sin tiempo de inactividad, presto atención a las estrategias de liberación atómica con symlinks y Validación de OPcache. Tras el cambio, borro selectivamente las cachés sin descartarlo todo. Esto mantiene las latencias de cola estables y los nuevos despliegues aterrizan rápidamente en un estado caliente. Importante: Los permisos y propietarios de los archivos deben ser correctos, de lo contrario los trabajadores FPM o LSAPI bloquearán las nuevas versiones.

Sockets frente a TCP: decisiones arquitectónicas con consecuencias

El manipulador se conecta a través de Enchufe Unix o a través de TCP. Los sockets ahorran sobrecarga y suelen ofrecer latencias mínimamente mejores en un host. TCP merece la pena si el servidor web y el manejador se ejecutan por separado o si quiero distribuir pools entre varios nodos. Escala me gustaría. Para TCP, defino los tiempos de espera, keep-alive y backlog de forma limpia para que no se produzcan errores 502/504 durante los picos de carga. En configuraciones Apache, presto atención al número de proxy workers activos, en Nginx a los límites de conexiones abiertas. Con LSAPI, LiteSpeed maneja muchas cosas internamente, pero sigo comprobando el backlog y las colas regularmente bajo carga.

Superviso la longitud de la cola en el estado de FPM, la utilización de los trabajadores y la saturación de la CPU. Una cola alta con baja utilización a menudo indica cuellos de botella en el frontend (por ejemplo, muy pocos trabajadores Nginx) o Frenos de E/S allí. Sólo cuando conozco el cuello de botella aumento los procesos hijo o ajusto los parámetros de red.

Supervisión, métricas y depuración

Para la observación me baso en Supervisión holísticaRegistros del servidor web, estado de FPM, métricas del sistema (CPU, RAM, E/S), registros de aplicaciones y comprobaciones sintéticas. Especialmente valioso es el FPMSlowlog, para detectar valores atípicos. Correlaciono las latencias P95/P99 con los picos de CPU, la tasa de aciertos de OPcache, el número de procesos en ejecución y las latencias de la base de datos. Si la latencia P99 aumenta, compruebo primero las colas y los tiempos de espera entre el proxy y el gestor.

En caso de incidente, trabajo desde fuera hacia dentro: 1) códigos de error HTTP y tiempo, 2) errores de proxy/servidor web, 3) colas de manejadores y estados de los trabajadores, 4) registros de aplicaciones, 5) sistemas backend (BD, caché, sistema de archivos). Causas frecuentes de 502/504 son tiempos de espera demasiado estrictos, bloqueo de flujos ascendentes o agotado Capacidades de la piscina. Contramedidas sencillas: tiempos de espera realistas, límites claros y alertas que antes de de agotamiento.

Sistemas de archivos, realpath y detalles de OPcache

Los accesos a archivos tienen un mayor impacto en la latencia de lo que mucha gente espera. Presto atención a los Vías de almacenamiento para código y plantillas. En los sistemas de archivos de red (por ejemplo, NFS), los parámetros realpath y OPcache son críticos. Un realpath_cache_size suficientemente grande y un ttl adecuado evitan resoluciones de rutas permanentes. En la OPcache, dimensiono memory_consumption, interned_strings_buffer y el número de Tablas hash Configuro validate_timestamps y revalidate_freq para que coincidan con el flujo de trabajo de despliegue, de modo que los cambios surtan efecto rápidamente pero no se activen comprobaciones cada segundo.

Para grandes bases de código vale la pena Precarga para clases y funciones centrales. Esto ahorra a los trabajadores de FPM o LSAPI tiempo de CPU en la ruta caliente. Sólo pruebo JIT donde hay verdaderos cuellos de botella de CPU (mucha lógica numérica). JIT raramente aporta ventajas para el CMS clásico; una configuración OPcache limpia y una ruta de E/S rápida son más importantes.

Conexión de base de datos y caché: evite la latencia

Muchos problemas de rendimiento no tienen su origen en el gestor, sino en Bases de datos y cachés. Superviso los tiempos de ejecución de las consultas, los grupos de conexiones y los bloqueos. Las conexiones persistentes pueden ayudar, pero vincular RAM en los trabajadores. Por lo tanto, dimensiono pm.max_children de acuerdo con los límites de conexión de la base de datos y controlo los tiempos de espera. Para los accesos a Redis/Memcached, la baja latencia de red y los tiempos de espera también son cruciales. Utilizo el rastreo en la aplicación para reconocer y reducir las consultas N+1 - esto reduce la carga en el manejador y el backend al mismo tiempo.

A menudo tiene sentido en un entorno altamente competitivo, escribir desacoplar los procesos (colas, trabajos asíncronos) y los accesos de lectura de la caché. De este modo, las solicitudes del front-end son cortas y se reduce la variabilidad de los tiempos de respuesta.

Aspectos relacionados con contenedores, chroot y SO

Cualquiera que utilice FPM o LSAPI en reciclaje de comida gana flexibilidad con las versiones y los límites. Son importantes unos límites correctos, un programador de procesos eficiente y unas cuotas de CPU/memoria adecuadas. Las cuotas que son demasiado duras causan tartamudeo en las latencias de P99. En configuraciones clásicas, chroot/jail o el aislamiento de usuarios mediante espacios de nombres ayuda a separar estrictamente los accesos a los archivos. Mantengo las imágenes magras para mantener los tiempos de arranque en frío corto (por ejemplo, después de un despliegue) y precalentar las piscinas antes de que el tráfico cambia.

Rotación de registros y Contrapresión-Las estrategias son obligatorias: los discos llenos o los escritores de logs bloqueantes tienen un efecto directo en los tiempos de respuesta. También calibro las estrategias swappiness, HugePages (cuando procede) y NUMA en hosts con muchos núcleos para que los trabajadores no se vean ralentizados por los accesos a la memoria entre nodos.

Unidades LSAPI y FPM en funcionamiento

LSAPI se beneficia de procesos estables y duraderos y de un envío eficiente de peticiones. Regulo el número máximo de peticiones por trabajador para limitar los efectos de las fugas de memoria y controlar los reinicios en operación en vivo. Con FPM elijo a la carta para sitios con tráfico irregular, dinámico Defino pm.max_requests para que las fugas esporádicas o la fragmentación no jueguen un papel importante. Establezco request_slowlog_timeout lo suficientemente cerca como para reconocer los cuelgues reales con antelación, pero no tanto como para que las operaciones complejas de administración hagan sonar la alarma constantemente.

Para ambos mundos, verifico el Vías de señalización para las recargas y definir rutas de escalado si los trabajadores no se reinician limpiamente. Esto evita que un despliegue en mitad del día cause interrupciones en la plataforma.

Lista de control: Selección y puesta a punto en la práctica

• Definir objetivo: máximo Compatibilidad (FPM) frente a latencia de cola mínima (LSAPI) frente a separación muy dura (CGI).
• Aclarar el papel del servidor: Configuración de un solo host (socket Unix) o niveles separados (TCP) - Establecer tiempos de espera/backlog adecuadamente.
• Pools por cuenta/sitio: UID/GID propio, límites estrictos de memoria, peticiones y tiempo; activar slowlog.
• OPcache: tamaño suficiente, alta tasa de aciertos, estrategia de revalidación adecuada para el despliegue; precarga si es necesario.
• Almacenamiento: fast path para código/cache, dimension realpath cache, observe las características especiales de NFS.
• BD/Cache: Conexiones y tiempos de espera consistentes con pm.max_children; eliminar consultas N+1.
• Capa de caché: combinar proxy inverso, caché de páginas y caché de aplicaciones; invalidar en lugar de vaciar a ciegas.
• Observabilidad: P95/P99, longitud de la cola, estados de los trabajadores, tasa de éxito de OPcache, latencias de E/S y backend de un vistazo.
• Despliegues: Agraciado recargas, calentamiento, despliegues atómicos, invalidación selectiva de caché.
• Planificación de la capacidad: reservas a reventar, sin exceso de reservas; evaluar de forma realista los costes/beneficios de las licencias LSAPI.

Brevemente resumido: mi clasificación

Para entornos de alojamiento mixtos PHP-FPM el mejor equilibrio entre rendimiento, aislamiento y compatibilidad. En las pilas LiteSpeed, LSAPI aporta ventajas mensurables en términos de latencias de cola y consumo de RAM. CGI es adecuado para una separación estricta en casos nicho, pero se queda atrás en proyectos dinámicos. Yo confío inicialmente en FPM con límites de pool claros, OPcache activado y una configuración limpia del servidor web. Si esperas mucha competencia, prueba LSAPI en LiteSpeed y luego toma una decisión. Coste-beneficio-decisión.