Comparativa: Nginx Unit vs PHP‑FPM para ejecutar aplicaciones PHP monolito en contenedores

Por · Publicado el · 9 min de lectura

Contenedores marítimos azules apilados contra un cielo despejado
Representa topologías y despliegues en entornos conteinerizados. Foto: Jan van der Wolf / Pexels

Esta comparativa Nginx Unit vs PHP‑FPM para ejecutar aplicaciones PHP monolito en contenedores explica diferencias reales de arquitectura, rendimiento, operación y seguridad. Verás criterios prácticos para elegir cada uno, impactos en el despliegue y en la observabilidad, y rutas de migración con bajo riesgo para tu entorno conteinerizado.

Arquitectura y modelo de procesos: cómo funciona cada uno

Nginx Unit es un servidor de aplicaciones con enrutamiento integrado y API de configuración dinámica. Atiende HTTP directamente y gestiona procesos de la aplicación PHP internamente, sin necesidad de un Nginx separado para el contenido dinámico.

PHP‑FPM es un gestor de procesos FastCGI para PHP. Requiere un servidor web al frente (como Nginx o Traefik) para recibir HTTP, servir estáticos y hacer proxy al pool FPM mediante socket o TCP.

En contenedores, el patrón común con FPM es usar dos contenedores: uno para el servidor web y otro para PHP‑FPM. Con Unit, suele usarse un único contenedor para servir HTTP y PHP; aun así, puedes colocarlo detrás de un proxy reverso si necesitas funcionalidades adicionales.

Ambos adoptan múltiples workers para concurrencia. La eficiencia depende de OPcache, I/O, número de workers y del perfil de carga.

  • Unit: servidor de aplicaciones con HTTP/TLS y API de configuración.
  • PHP‑FPM: necesita un servidor web al frente (Nginx/Traefik).
  • En contenedores: Unit puede simplificar la topología; FPM separa responsabilidades.

Rendimiento y latencia: qué influye realmente

Sin microbenchmarks estandarizados, no hay un ganador universal. En cargas de trabajo de monolitos PHP, la latencia y el throughput tienden a depender más de OPcache, base de datos y I/O que del runtime en sí.

Nginx Unit elimina una hop FastCGI y puede reducir copias de datos en algunos escenarios. PHP‑FPM, cuando está bien ajustado, ofrece throughput estable y predecible mediante el dimensionamiento de los pools.

En ambos casos, calienta el OPcache y ajusta el número de workers según CPU y memoria del contenedor. Observa p95/p99 y no solo la media de latencia.

  • Calienta y valida OPcache antes de las pruebas.
  • Mide p95/p99 bajo carga representativa.
  • Ajusta workers según CPU/memoria del contenedor.
  • Evita I/O síncrono innecesario en requests.

Configuración, DX y reconfiguración sin downtime

Nginx Unit ofrece una API REST para configurar rutas, listeners y aplicaciones. Los cambios se aplican de forma dinámica, sin reload de proceso, lo que facilita ajustes finos y automatizaciones en entornos de contenedores.

En PHP‑FPM, los cambios en el pool o en php.ini requieren reload del servicio; es posible hacerlo de forma graciosa, pero es un paso operativo extra. A cambio, la configuración es simple y ampliamente conocida.

Si usas un proxy reverso dedicado, compara opciones como Traefik y Nginx según tu escenario en la página de Traefik vs Nginx como reverse proxy.

  • Unit: cambios vía API, atómicos y dinámicos.
  • FPM: reload gracioso del proceso master para aplicar configs.
  • Automatización: Unit facilita cambios frecuentes bajo orquestación.

Observabilidad, logs y métricas

Con Unit, tienes logs estructurados y una API de estado. Integrar con Prometheus suele requerir un exporter o recolección vía sidecar; estandariza el formato de logs para tu stack.

En PHP‑FPM, la página /status y el slowlog ayudan en el diagnóstico. Hay exporters maduros para Prometheus y Grafana. Consulta el paso a paso para exponer métricas del PHP‑FPM para Prometheus.

Para logs de aplicación, centraliza y correlaciona con tu proxy reverso. Para trazas, el impacto es similar en ambos runtimes; céntrate en la instrumentación del código.

  • FPM: page /status, slowlog y exporters ampliamente usados.
  • Unit: status API y logs estructurados; usa exporter/sidecar.
  • Estandariza la correlación de request ID entre proxy y app.

Seguridad y aislamiento en contenedores

Ambos funcionan bien ejecutándose como usuario no root dentro del contenedor y pueden aislar procesos por app/pool. En contenedores, chroot adicionales suelen aportar poco más allá del aislamiento que ya ofrece el runtime del contenedor.

Nginx Unit puede terminar TLS directamente. Con PHP‑FPM, la terminación TLS queda en el servidor/proxy al frente. En ambos casos, mantén la superficie mínima en la imagen y actualiza dependencias de PHP con frecuencia.

Ajusta permisos de directorios de upload/cache y restringe extensiones ejecutables en FPM. En Unit, aísla rutas administrativas y minimiza la superficie de la API de configuración.

  • Ejecuta como usuario no root.
  • Minimiza paquetes y módulos en la imagen.
  • Separa volúmenes de upload y cache del código.

Cuándo elegir cada uno: criterios prácticos

Usa criterios de operación, equipo y requisitos no funcionales. A continuación, señales que inclinan la balanza en cada dirección.

  • Prefiere Nginx Unit si: quieres configuración dinámica vía API; deseas consolidar servidor web y PHP en el mismo contenedor; necesitas rutas y listeners mutables sin reload.
  • Prefiere PHP‑FPM si: tu equipo ya domina Nginx+FPM; necesitas integraciones maduras de métricas/slowlog; buscas previsibilidad de tuning con pools y procesos.
  • Consideración común: separa estáticos en un CDN. Para despliegue sin downtime, usa rutas por versión o intercambios atómicos de contenedores, como en el deploy blue-green con Docker Compose.
  • Si observas crecimiento de memoria en FPM, investiga patrones de asignación y OPcache. Consulta consejos en la guía de fuga de memoria en PHP‑FPM: cómo resolver.

Tabla comparativa rápida

Resumen lado a lado de puntos de decisión frecuentes.

Aspecto Nginx Unit PHP‑FPM Comentario
Arquitectura Servidor de aplicaciones con HTTP/TLS y API Gestor FastCGI; necesita servidor web/proxy Topologías diferentes; ambos estables en producción
Reconfiguración Dinámica vía API, sin reload Reload gracioso del servicio Unit favorece cambios frecuentes
Deploy sin downtime Rutas/versionado configurables en la API Intercambio de contenedores y reloads graciosos Blue/Green funciona bien en ambos
Métricas/healthchecks Status API; requiere exporter /status, slowlog y exporters consolidados Ecosistema de observabilidad del FPM es amplio
Logs Estructurados; formato configurable Access/error logs vía servidor web + FPM slowlog Estandariza correlación entre capas
TLS Puede terminar TLS nativamente Terminación en proxy/servidor web En contenedores, TLS en el proxy es común
Consumo de memoria Procesos por app; footprint reducido Pools por worker; footprint predecible Depende de OPcache y workers
Throughput/latencia Competitivo; elimina hop FastCGI Muy competitivo cuando está bien ajustado Perfil de carga y I/O dictan el resultado
Múltiples versiones PHP Por imagen/binarios instalados Por pools/instalación paralela En contenedores, aisla por imagen
Complejidad operacional Menos piezas cuando se usa solo Separación clara de responsabilidades Elige según la madurez del equipo

Camino de migración y validación de bajo riesgo

Para probar Nginx Unit, levanta un entorno paralelo apuntando a la misma base y storage de staging. Replica variables de entorno y el calentamiento del OPcache. Compara p95/p99 y tasas de error.

Implementa validaciones de rutas y headers para redirigir solo una fracción del tráfico. Estrategias de canary o blue/green en contenedores reducen riesgos sin exigir cambios en la aplicación.

Documenta el rollback y mantén el pipeline reproducible. Revisa también criterios de proxy reverso en la comparación de Traefik vs Nginx como reverse proxy.

  • Prueba en paralelo con datos de staging representativos.
  • Calienta OPcache y ejecuta pruebas de carga controladas.
  • Planifica rollback simple: cambiar tag de imagen o ruta.

Notas técnicas útiles y referencias oficiales

Para ajustes finos de PHP‑FPM (pools, pm, slowlog y status), consulta la documentación oficial. Para rendimiento, revisa la configuración de OPcache y monitoriza aciertos/invalidaciones bajo carga.

  • PHP‑FPM: configuración y página /status en php.net.
  • OPcache: parámetros y buenas prácticas en la documentación oficial.

Preguntas frecuentes

¿Nginx Unit siempre es más rápido que PHP‑FPM?

No hay un ganador universal. El rendimiento depende de tu código, OPcache, I/O y del ajuste de workers. Mide en staging con tráfico representativo y compara p95/p99, no solo promedios.

¿Puedo usar Nginx o Traefik delante de Nginx Unit?

Sí. Aunque Unit puede atender HTTP/TLS directamente, muchos equipos prefieren un proxy reverso dedicado para centralizar TLS, compresión y enrutamiento entre servicios.

¿Cómo monitorizar PHP‑FPM en producción?

Activa la página /status, el slowlog y recoge métricas con un exporter para Prometheus. Estandariza labels y la correlación con el proxy reverso. Hay una guía paso a paso en nuestra página de métricas del FPM.

¿Migrar a Unit exige cambiar mi código PHP?

En la mayoría de los monolitos, no. La aplicación sigue siendo PHP. Los ajustes suelen quedar en la capa de configuración del servidor y en rutas/paths. Prueba integraciones con upload, cache y headers.

¿Cuál es mejor para despliegue sin downtime en contenedores?

Ambos soportan bien blue/green y canary. Con Unit puedes ajustar rutas vía API. Con FPM, el intercambio atómico de contenedores y el reload gracioso del servidor son estrategias consolidadas.

¿OPcache funciona igual en ambos?

Sí. OPcache es un componente de PHP, no del runtime web. Ajusta parámetros como memory_consumption y tiempo de validez, y verifica métricas de acierto bajo carga.

¿Quieres validar la mejor opción para tu monolito PHP en contenedores?

Hablemos de tu arquitectura, métricas actuales y requisitos. Podemos diseñar un plan de pruebas con escenarios de carga, criterios de rollback y estimación del esfuerzo para migración o tuning.

Hablar sobre tu arquitectura PHP

Ver también