Cloudflare Workers suma profiling on-demand con flamegraphs

¿Cómo funciona el profiling on-demand en Cloudflare Workers?

Cloudflare acaba de activar profiling on-demand de CPU y memoria para Workers y Durable Objects, con flamegraphs interactivos. En una prueba interna, el equipo detrás del binding de R2 detectó una función que consumía más del 5% del CPU por recorrer dos veces el mismo árbol JSON: tras el fix, quedó 2,7 veces más rápida.

Hasta ahora, Workers solo soportaba profiling local a través de Chrome DevTools. Como explica Cloudflare en su blog, el Worker no recibe el mismo tipo ni el mismo volumen de requests en local que en producción, así que cualquier foto que obtuvieras con DevTools era siempre parcial. Con el nuevo profiling on-demand, puedes capturar un perfil del código mientras corre en producción, sin tener que reproducir tráfico artificial.

¿Qué se puede hacer con los flamegraphs de Cloudflare?

• Capturar perfiles de CPU o memoria de un Worker activo, con la duración que elijas (el ejemplo de la documentación usa 5 segundos).
• Visualizarlos como flamegraphs interactivos en el dashboard, donde cada rectángulo representa una llamada a función y el ancho refleja CPU o memoria consumida.
• Descargar el archivo .pprof para análisis externo con herramientas como pprof o Speedscope.
• Apuntar a una versión específica del Worker (Cloudflare perfila la versión desplegada, no inicia un isolate nuevo).
• Apuntar a un Durable Object por nombre: el runtime enruta la petición al metal exacto que aloja al actor primario.

El formato de salida es pprof y la captura se hace con el profiler de V8 a 1 milisegundo de intervalo de muestreo. Para lanzarla hay dos caminos:

• CLI: cf workers versions profile latest --worker-id "$WORKER_ID_OR_NAME" --duration-ms 5000 --profile-type cpu > worker-cpu.pprof
• Dashboard: Build → Compute → Workers & Pages, elegir el Worker, abrir la pestaña Observability y seleccionar Flamegraph.

¿Qué casos reales resolvió Cloudflare con su propio profiler?

Cloudflare compartió dos ejemplos internos con cifras concretas.

CPU: 2,7x más rápido eliminando trabajo duplicado

En un perfil de CPU del Worker que implementa el binding de R2, la función genericR2JsonReplacer aparecía como la segunda candidata a optimizar, con más del 5% del tiempo de CPU. La causa: aunque JSON.stringify ya recorría el árbol JSON, el replacer también lo recorría por su cuenta, procesando hasta cinco veces los nodos anidados. Tras corregir la doble iteración, la función quedó 2,7 veces más rápida.

En el mismo perfil, una segunda optimización: una llamada duplicada a metrics() dentro de la función ship() representaba un 1% del CPU por sí sola. Almacenar el resultado en una variable eliminó ese trabajo redundante.

Memoria: de 133 MB a 118 MB en P999

Otro equipo tenía un Worker que se evictaba frecuentemente con error "Exceeded Memory" porque el percentil 99,9 de uso estaba en 133 MB, rozando el límite de 128 MB que impone la plataforma. El perfilado de heap mostró que el código de Prometheus, que se creía deshabilitado, representaba aproximadamente 66,7% de las asignaciones de memoria.

El equipo eliminó completamente la ruta de Prometheus y la memoria cayó a estos niveles:

Percentil	Antes (MB)	Después (MB)
P50	70	54
P90	94	79
P99	113	97
P999	133	118

El P999 recuperó ~10 MB de headroom bajo el límite de 128 MB.

¿Por qué el profiling en producción es distinto al de local?

Cloudflare tuvo que resolver un problema de arquitectura que no existe en un servidor tradicional:

• Los Workers son réplicas distribuidas en distintos data centers y metales físicos.
• Para Durable Objects, hay que localizar al actor primario exacto en cualquier parte del mundo.
• Cloudflare no inicia un isolate nuevo para perfilar: si el Worker no recibe tráfico, no hay nada que capturar.

Una vez localizado el isolate, el runtime solo retiene el lock del isolate durante el ciclo de vida del profiler (crear el profiler, esperar la duración, detener y serializar). Durante los segundos de captura, el Worker sigue ejecutando requests con normalidad. Si el runtime mantuviera el lock bloqueado, la captura reflejaría un Worker congelado, no la realidad.

Para que la cifra cobre dimensión: Cloudflare corre su propio navegador headless para agentes de IA, Kitesurf, sobre Workers, según reportó TechCrunch en agosto de 2026. El tipo de cargas que ya pasan por la plataforma hacen que cualquier regresión de CPU o memoria se pague directamente en costos de infraestructura.

¿Qué limitaciones tiene y qué viene después?

Cloudflare reconoce tres límites del modo on-demand:

• Hay que iniciar la sesión manualmente, lo que significa perder eventos puntuales donde el Worker se porta mal.
• El memory profiler solo muestra asignaciones ocurridas durante la ventana de profiling, no lo que pasó durante el arranque.
• El Worker necesita tráfico real en la versión seleccionada para que haya algo que capturar.

El siguiente paso, ya en desarrollo, es continuous profiling: captura automática de muestras que puedas explorar después en el dashboard, sin necesidad de disparar la sesión manualmente.

¿Qué significa esto para tu startup?

Si ya corres lógica en Cloudflare Workers o estás evaluando el edge para reducir latencia, el profiling on-demand cierra un agujero doloroso: hasta hoy dependías de logs y métricas agregadas, que te dicen que algo consume CPU o memoria, pero no qué función exactamente.

Tres acciones concretas para empezar hoy:

• Activa source maps en tus proyectos TypeScript antes de perfilar. Sin source maps, los nombres de funciones salen ofuscados y el flamegraph será inútil para encontrar el código real que optimizar.
• Captura al menos dos o tres perfiles antes de optimizar. Un solo perfil puede esconder picos que solo aparecen bajo carga; revisa la vista de tabla ordenada por Samples además del flamegraph.
• Apunta siempre a una versión con tráfico real. Cloudflare no inicia un isolate solo para perfilar, así que si despliegas una versión que nadie está usando, la captura no tendrá muestras que valgan la pena.

Conclusión

El profiling on-demand con flamegraphs no es una herramienta de marketing: es la pieza que faltaba para que Workers pase de "rápido por diseño" a "rápido y verificable". Y la pista más importante está en los propios números de Cloudflare: un 66,7% de memoria desperdiciada por un código que se creía deshabilitado, un 2,7x de speedup eliminando un recorrido doble del árbol JSON. Lo que se mide se optimiza, y Cloudflare acaba de darte la regla en el edge.

Fuentes

• Introducing on-demand CPU and memory profiling with flamegraphs for Workers and Durable Objects (Cloudflare Blog)
• Cloudflare launches Kitesurf, a browser built for AI agents (TechCrunch)