{"id":142,"date":"2026-02-02T19:41:57","date_gmt":"2026-02-02T23:41:57","guid":{"rendered":"https:\/\/juredev.com\/blog\/?p=142"},"modified":"2026-02-28T09:04:05","modified_gmt":"2026-02-28T13:04:05","slug":"frankenphp-no-es-magia-rendimiento-contexto-e-infraestructura","status":"publish","type":"post","link":"https:\/\/juredev.com\/blog\/2026\/02\/frankenphp-no-es-magia-rendimiento-contexto-e-infraestructura\/","title":{"rendered":"FrankenPHP no es magia: rendimiento, contexto e infraestructura"},"content":{"rendered":"\n

En los \u00faltimos meses FrankenPHP<\/a><\/strong> ha estado en boca de todos en el mundo PHP<\/a><\/strong>. Hay art\u00edculos, benchmarks, charlas en conferencias y posts en redes que lo pintan como el gran salto evolutivo para aplicaciones modernas, sobre todo si usas Symfony<\/a><\/strong> (que es donde lo he estado probando yo) o Laravel<\/strong>.<\/p>\n\n\n\n

Los n\u00fameros que se ven suelen ser muy tentadores: latencia m\u00e1s baja, mucho m\u00e1s throughput y hasta un servidor HTTP embebido que simplifica el stack. Suena incre\u00edble\u2026 y en buena medida lo es.<\/p>\n\n\n\n

Pero en medio de toda esa emoci\u00f3n 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\u00f3n. Este art\u00edculo no va en contra de FrankenPHP<\/strong>. Al contrario, me parece una herramienta genial. Lo que quiero es invitarte a mirarlo con ojos cr\u00edticos y a evaluar bien todo lo que implica antes de meterlo en producci\u00f3n.<\/p>\n\n\n\n

Por qu\u00e9 todos queremos m\u00e1s rendimiento (y es normal)<\/h2>\n\n\n\n

Cuando una aplicaci\u00f3n empieza a crecer, los problemas aparecen r\u00e1pido: las respuestas se ralentizan, el escalado se pone caro y el servidor se queja. En PHP<\/strong>, uno de los culpables cl\u00e1sicos es el famoso bootstrap o proceso de arranque del framework en cada request: contenedor de dependencias, lectura de configuraci\u00f3n, autoloading\u2026 todo se reinicia desde cero una y otra vez.<\/p>\n\n\n\n

FrankenPHP<\/strong> en modo worker va directo contra ese dolor: mantiene la aplicaci\u00f3n cargada en memoria entre peticiones. La idea es buen\u00edsima y, cuando las condiciones son las adecuadas, el salto de rendimiento es real. El tema es que mucha gente asume que esa ganancia viene \u201cgratis\u201d y que sirve igual para cualquier proyecto. Y ah\u00ed empiezan los problemas.<\/p>\n\n\n\n

PHP-FPM: simple, predecible y todav\u00eda muy vivo<\/h2>\n\n\n\n

PHP-FPM<\/strong> lleva a\u00f1os siendo el est\u00e1ndar por algo muy concreto: cada petici\u00f3n arranca en un entorno limpio y, cuando termina, libera casi todo lo que us\u00f3. Eso lo hace seguro y predecible, sobre todo en infraestructuras modestas o con tr\u00e1fico que sube y baja mucho (picos de hora pico, noches tranquilas, etc.).<\/p>\n\n\n\n

En un VPS<\/strong> o servidor peque\u00f1o puedes meter varios proyectos sin dramas. Los procesos se \u201cduermen\u201d cuando no hay tr\u00e1fico y consumen muy poca RAM<\/strong>. FrankenPHP<\/strong> worker, en cambio, desde el minuto uno ya est\u00e1 reservando memoria para tener todo el framework caliente. Es como un compa\u00f1ero de piso que ocupa mucho espacio desde el primer d\u00eda y no sabe muy bien compartir.<\/p>\n\n\n\n

Modo Worker: mucha potencia\u2026 y nuevos compromisos<\/h2>\n\n\n\n

Cambiar al modo worker implica romper un principio b\u00e1sico de PHP<\/strong> tradicional: el ciclo de vida ef\u00edmero de cada request. Ahora hablamos de procesos que viven mucho tiempo y manejan muchas peticiones seguidas.<\/p>\n\n\n\n

Eso trae mejoras espectaculares de rendimiento, pero tambi\u00e9n nuevas responsabilidades que no son opcionales:<\/p>\n\n\n\n

    \n
  • Higiene del c\u00f3digo al m\u00e1ximo:<\/strong> En PHP-FPM<\/strong> un peque\u00f1o memory leak o una variable est\u00e1tica mal manejada suele pasar desapercibida (el proceso muere pronto). En FrankenPHP<\/strong> worker eso se convierte en una cuenta regresiva hacia el OOM killer. Si tu c\u00f3digo va dejando basura en memoria, tarde o temprano el worker se come toda la RAM disponible.<\/li>\n\n\n\n
  • Gesti\u00f3n del estado persistente:<\/strong> En FPM<\/strong> el \u201cno me acuerdo de nada\u201d es una ventaja. En worker mode, si dejas un servicio sucio en Symfony<\/strong> (un EntityManager<\/strong> con cambios pendientes, una conexi\u00f3n abierta rara, un static mal reseteado\u2026), ese estado se queda ah\u00ed y contamina las siguientes peticiones.<\/li>\n<\/ul>\n\n\n\n

    Hacer este cambio no es solo \u201cactivar una opci\u00f3n\u201d. Requiere disciplina, revisar el c\u00f3digo con lupa, pruebas espec\u00edficas para worker y, en muchos casos, ajustes en librer\u00edas o patrones que dabas por sentados.<\/p>\n\n\n\n

    Infraestructura: el gran tema que casi nadie menciona<\/h2>\n\n\n\n

    La mayor\u00eda de benchmarks y comparativas se obsesionan con los requests por segundo. Muy pocos hablan de:<\/p>\n\n\n\n

      \n
    • Cu\u00e1nta RAM consume realmente cada worker caliente (y s\u00ed, suele ser bastante m\u00e1s que un proceso FPM<\/strong> en reposo).<\/li>\n\n\n\n
    • Cu\u00e1ntos workers paralelos puedes correr de verdad en tu m\u00e1quina o contenedor antes de tocar techo.<\/li>\n\n\n\n
    • Qu\u00e9 pasa cuando tienes nodos con l\u00edmites duros de memoria (Cloud Run, Fly.io, VPS baratos, etc.).<\/li>\n<\/ul>\n\n\n\n

      He visto casos en los que adoptar FrankenPHP<\/strong> worker mejora el rendimiento te\u00f3rico\u2026 pero termina necesitando m\u00e1s instancias, m\u00e1s RAM o reinicios frecuentes para no colapsar. Resultado: un stack que en papel es m\u00e1s r\u00e1pido, pero en la vida real es m\u00e1s caro o inestable.<\/p>\n\n\n\n

      A veces simplificar la infraestructura (un solo binario, adi\u00f3s Nginx<\/strong> + FPM<\/strong>) termina complicando el d\u00eda a d\u00eda: hay que pensar m\u00e1s en recargas graceful, en reinicios programados de workers, en c\u00f3mo manejar estado persistente sin romper cosas.<\/p>\n\n\n\n

      La pregunta que yo siempre me hago es: \u00bfD\u00f3nde prefiero tener la complejidad: en la configuraci\u00f3n del servidor web o en la l\u00f3gica de vida de mis servicios?<\/strong><\/p>\n\n\n\n

      Una postura m\u00e1s realista (y creo que m\u00e1s honesta)<\/h2>\n\n\n\n

      No todos los proyectos necesitan exprimir cada milisegundo. Muchos son CRUDs cl\u00e1sicos, paneles de administraci\u00f3n, APIs internas o sitios con tr\u00e1fico moderado donde lo m\u00e1s importante es estabilidad, costes predecibles y que \u201csimplemente funcione\u201d.<\/p>\n\n\n\n

      Si tuviera que resumir mi visi\u00f3n actual en una frase ser\u00eda esta:<\/p>\n\n\n\n

      \n

      PHP-FPM<\/strong> sigue siendo la opci\u00f3n \u201csegura\u201d y conservadora para infraestructuras limitadas o tr\u00e1fico variable, mientras que FrankenPHP<\/strong> en modo worker es una herramienta muy potente\u2026 pero selectiva y exigente.<\/p>\n<\/blockquote>\n\n\n\n

      FrankenPHP brilla cuando:<\/p>\n\n\n\n

        \n
      • El tr\u00e1fico es relativamente constante (no hay largos periodos de inactividad).<\/li>\n\n\n\n
      • El coste de bootstrap del framework es un cuello de botella real y medible.<\/li>\n\n\n\n
      • El equipo tiene madurez operativa para manejar procesos de larga duraci\u00f3n, revisar leaks y probar en entornos que simulen worker mode.<\/li>\n<\/ul>\n\n\n\n

        No se trata de elegir lo m\u00e1s r\u00e1pido, sino lo que mejor encaja<\/h2>\n\n\n\n

        A m\u00ed FrankenPHP<\/strong> me encanta y lo uso en un proyecto donde las condiciones son las adecuadas. Pero hoy por hoy no es una soluci\u00f3n universal, sobre todo cuando los recursos son ajustados o el equipo no est\u00e1 preparado para el cambio de mentalidad.<\/p>\n\n\n\n

        Antes de saltar, vale la pena hacerse unas preguntas inc\u00f3modas:<\/p>\n\n\n\n

          \n
        • \u00bfEst\u00e1 mi c\u00f3digo realmente preparado para vivir \u201cpara siempre\u201d sin limpiarse?<\/li>\n\n\n\n
        • \u00bfMi servidor (o contenedor) tiene suficiente RAM y aire para mantener varios workers calientes sin ahogarse?<\/li>\n\n\n\n
        • \u00bfEstoy dispuesto a invertir tiempo en pruebas espec\u00edficas, monitoreo de memoria y ajustes finos?<\/li>\n<\/ul>\n\n\n\n

          Porque al final, la optimizaci\u00f3n prematura sigue siendo una de las principales fuentes de dolores de cabeza\u2026 especialmente cuando se ignora por completo su impacto en la infraestructura.<\/p>\n\n\n\n

          \u00bfQu\u00e9 opinas t\u00fa? \u00bfYa lo est\u00e1s usando en producci\u00f3n? \u00bfEn qu\u00e9 tipo de proyectos te ha funcionado mejor? Me encantar\u00eda leer tu experiencia en los comentarios.<\/p>\n","protected":false},"excerpt":{"rendered":"

          En los \u00faltimos meses FrankenPHP ha estado en boca de todos en el mundo PHP. Hay art\u00edculos, 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\u00fameros que se […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18],"tags":[15],"class_list":["post-142","post","type-post","status-publish","format-standard","hentry","category-guia","tag-php"],"_links":{"self":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/posts\/142","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/comments?post=142"}],"version-history":[{"count":0,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/posts\/142\/revisions"}],"wp:attachment":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/media?parent=142"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/categories?post=142"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/tags?post=142"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}