En los últimos meses FrankenPHP ha estado en boca de todos en el mundo PHP. Hay artículos, benchmarks, charlas en conferencias y posts en redes que lo pintan como el gran salto evolutivo para aplicaciones modernas, sobre todo si usas Symfony (que es donde lo he estado probando yo) o Laravel.
Los números que se ven suelen ser muy tentadores: latencia más baja, mucho más throughput y hasta un servidor HTTP embebido que simplifica el stack. Suena increíble… y en buena medida lo es.
Pero en medio de toda esa emoción por ganar milisegundos, hay algo que se suele pasar por alto: la infraestructura real y el contexto en el que vas a correr la aplicación. Este artículo no va en contra de FrankenPHP. Al contrario, me parece una herramienta genial. Lo que quiero es invitarte a mirarlo con ojos críticos y a evaluar bien todo lo que implica antes de meterlo en producción.
Por qué todos queremos más rendimiento (y es normal)
Cuando una aplicación empieza a crecer, los problemas aparecen rápido: las respuestas se ralentizan, el escalado se pone caro y el servidor se queja. En PHP, uno de los culpables clásicos es el famoso bootstrap o proceso de arranque del framework en cada request: contenedor de dependencias, lectura de configuración, autoloading… todo se reinicia desde cero una y otra vez.
FrankenPHP en modo worker va directo contra ese dolor: mantiene la aplicación cargada en memoria entre peticiones. La idea es buenísima y, cuando las condiciones son las adecuadas, el salto de rendimiento es real. El tema es que mucha gente asume que esa ganancia viene “gratis” y que sirve igual para cualquier proyecto. Y ahí empiezan los problemas.
PHP-FPM: simple, predecible y todavía muy vivo
PHP-FPM lleva años siendo el estándar por algo muy concreto: cada petición arranca en un entorno limpio y, cuando termina, libera casi todo lo que usó. Eso lo hace seguro y predecible, sobre todo en infraestructuras modestas o con tráfico que sube y baja mucho (picos de hora pico, noches tranquilas, etc.).
En un VPS o servidor pequeño puedes meter varios proyectos sin dramas. Los procesos se “duermen” cuando no hay tráfico y consumen muy poca RAM. FrankenPHP worker, en cambio, desde el minuto uno ya está reservando memoria para tener todo el framework caliente. Es como un compañero de piso que ocupa mucho espacio desde el primer día y no sabe muy bien compartir.
Modo Worker: mucha potencia… y nuevos compromisos
Cambiar al modo worker implica romper un principio básico de PHP tradicional: el ciclo de vida efímero de cada request. Ahora hablamos de procesos que viven mucho tiempo y manejan muchas peticiones seguidas.
Eso trae mejoras espectaculares de rendimiento, pero también nuevas responsabilidades que no son opcionales:
- Higiene del código al máximo: En PHP-FPM un pequeño memory leak o una variable estática mal manejada suele pasar desapercibida (el proceso muere pronto). En FrankenPHP worker eso se convierte en una cuenta regresiva hacia el OOM killer. Si tu código va dejando basura en memoria, tarde o temprano el worker se come toda la RAM disponible.
- Gestión del estado persistente: En FPM el “no me acuerdo de nada” es una ventaja. En worker mode, si dejas un servicio sucio en Symfony (un EntityManager con cambios pendientes, una conexión abierta rara, un static mal reseteado…), ese estado se queda ahí y contamina las siguientes peticiones.
Hacer este cambio no es solo “activar una opción”. Requiere disciplina, revisar el código con lupa, pruebas específicas para worker y, en muchos casos, ajustes en librerías o patrones que dabas por sentados.
Infraestructura: el gran tema que casi nadie menciona
La mayoría de benchmarks y comparativas se obsesionan con los requests por segundo. Muy pocos hablan de:
- Cuánta RAM consume realmente cada worker caliente (y sí, suele ser bastante más que un proceso FPM en reposo).
- Cuántos workers paralelos puedes correr de verdad en tu máquina o contenedor antes de tocar techo.
- Qué pasa cuando tienes nodos con límites duros de memoria (Cloud Run, Fly.io, VPS baratos, etc.).
He visto casos en los que adoptar FrankenPHP worker mejora el rendimiento teórico… pero termina necesitando más instancias, más RAM o reinicios frecuentes para no colapsar. Resultado: un stack que en papel es más rápido, pero en la vida real es más caro o inestable.
A veces simplificar la infraestructura (un solo binario, adiós Nginx + FPM) termina complicando el día a día: hay que pensar más en recargas graceful, en reinicios programados de workers, en cómo manejar estado persistente sin romper cosas.
La pregunta que yo siempre me hago es: ¿Dónde prefiero tener la complejidad: en la configuración del servidor web o en la lógica de vida de mis servicios?
Una postura más realista (y creo que más honesta)
No todos los proyectos necesitan exprimir cada milisegundo. Muchos son CRUDs clásicos, paneles de administración, APIs internas o sitios con tráfico moderado donde lo más importante es estabilidad, costes predecibles y que “simplemente funcione”.
Si tuviera que resumir mi visión actual en una frase sería esta:
PHP-FPM sigue siendo la opción “segura” y conservadora para infraestructuras limitadas o tráfico variable, mientras que FrankenPHP en modo worker es una herramienta muy potente… pero selectiva y exigente.
FrankenPHP brilla cuando:
- El tráfico es relativamente constante (no hay largos periodos de inactividad).
- El coste de bootstrap del framework es un cuello de botella real y medible.
- El equipo tiene madurez operativa para manejar procesos de larga duración, revisar leaks y probar en entornos que simulen worker mode.
No se trata de elegir lo más rápido, sino lo que mejor encaja
A mí FrankenPHP me encanta y lo uso en un proyecto donde las condiciones son las adecuadas. Pero hoy por hoy no es una solución universal, sobre todo cuando los recursos son ajustados o el equipo no está preparado para el cambio de mentalidad.
Antes de saltar, vale la pena hacerse unas preguntas incómodas:
- ¿Está mi código realmente preparado para vivir “para siempre” sin limpiarse?
- ¿Mi servidor (o contenedor) tiene suficiente RAM y aire para mantener varios workers calientes sin ahogarse?
- ¿Estoy dispuesto a invertir tiempo en pruebas específicas, monitoreo de memoria y ajustes finos?
Porque al final, la optimización prematura sigue siendo una de las principales fuentes de dolores de cabeza… especialmente cuando se ignora por completo su impacto en la infraestructura.
¿Qué opinas tú? ¿Ya lo estás usando en producción? ¿En qué tipo de proyectos te ha funcionado mejor? Me encantaría leer tu experiencia en los comentarios.