Guía: perfilar CPU y memoria en Workers de Cloudflare en producción

Cómo capturar perfiles de CPU y memoria de un Worker o Durable Object en producción, leer el flamegraph y evitar los errores más comunes al interpretarlo.

Ingeniería de software

Cuando un Worker consume demasiada CPU o se acerca al límite de memoria, los logs y las métricas agregadas nos dicen que algo va mal, pero no dónde. Cloudflare ha lanzado perfilado de CPU y memoria bajo demanda para Workers y Durable Objects, que genera flamegraphs interactivos sobre código que ya se está ejecutando en producción.

En esta guía resumimos cómo plantear una sesión de perfilado, qué esperar del resultado y dónde están los límites de la técnica. Partimos de la cobertura de InfoQ y de la documentación de Cloudflare, así que conviene contrastar los detalles de la interfaz con ellas.

Lo que necesitas

• Un Worker o Durable Object ya desplegado y con tráfico real durante la captura.
• Acceso al panel de Workers Observability o a la herramienta de línea de comandos cf (consulta la referencia de instalación).
• Source maps activados si trabajas con TypeScript, para que los nombres de función sean legibles.
• Opcional: pprof o Chrome DevTools para analizar el perfil descargado fuera de línea.

En un flamegraph, cuanto más ancho el bloque, mayor parte del tiempo de CPU o de las asignaciones muestreadas.

Pasos para capturar un perfil

1. Identifica el síntoma: latencia alta, CPU elevada o memoria cerca del límite de 128 MB, según tus métricas y logs.
2. Elige el tipo de perfil. CPU si sospechas de cálculo redundante; memoria (heap) si sospechas de exceso de objetos o asignaciones.
3. Selecciona la versión desplegada del Worker. Si es un Durable Object, indica la instancia concreta por nombre.
4. Lanza la captura desde el panel de Workers Observability o desde la CLI mientras el objetivo recibe tráfico suficiente.
5. Abre el flamegraph, localiza los bloques más anchos y, si hace falta, descarga el perfil para analizarlo con pprof.

Cómo funciona por dentro

El perfilado apunta a un isolate que ya está en ejecución, no a uno nuevo, de modo que ves el código bajo tráfico real. Para CPU, el runtime arranca el perfilador de V8 con muestreo cada milisegundo, libera el bloqueo del isolate mientras las peticiones siguen su curso y lo recupera solo para detener la captura y recoger resultados.

Como un script puede tener isolates en varios centros de datos, la petición debe localizar uno activo de la versión pedida. En los Durable Objects, que son con estado y pueden cambiar de ubicación, la petición se enruta a la máquina que aloja ese objeto concreto.

# Esquema orientativo; los subcomandos exactos están en la documentación de Cloudflare
# 1. Elegir el Worker y su versión desplegada
# 2. Pedir un perfil de CPU o de heap
# 3. Descargar el resultado para análisis con pprof

No hemos inventado comandos concretos: la sintaxis de la CLI debe copiarse de la documentación oficial. Lo importante es el orden de trabajo: síntoma, tipo de perfil, objetivo, captura y análisis.

El perfil complementa a logs, métricas y trazas: estas dicen cuándo, el perfil dice dónde.

Qué esperar del resultado

CPU y memoria responden a preguntas distintas. Una función puede gastar mucha CPU sin asignar apenas memoria, y otra puede generar muchas asignaciones sin dominar el tiempo de ejecución. Por eso conviene capturar ambos perfiles antes de decidir dónde optimizar.

Cloudflare cuenta casos internos: un reemplazador JSON recursivo que recorría datos anidados una y otra vez, cuya corrección lo hizo, según la empresa, 2,7 veces más rápido; una llamada duplicada de métricas que suponía cerca del 1 % de la CPU; y código de Prometheus a medio desactivar que bajó el uso de memoria del percentil 99,9 de 133 MB a 118 MB al eliminarlo. Son cifras declaradas por el proveedor.

Truco Si la captura sale casi vacía, el problema suele ser poco tráfico durante la ventana. Lanza el perfil en un momento de carga y no olvides los source maps en TypeScript: sin ellos, los nombres del flamegraph serán difíciles de leer.

Ten presentes los límites. La captura bajo demanda no es monitorización continua: una ventana corta puede perder problemas intermitentes. Además, un perfil de heap registra las asignaciones durante la captura, no un retrato completo de la memoria retenida. Cloudflare dice que trabaja hacia el perfilado continuo, pero hoy hay que anticipar cuándo capturar.

Opinión · Mi apuesta a 12 meses

Creo que en los próximos doce meses el perfilado bajo demanda pasará de curiosidad a hábito en los equipos que usan Workers. El motivo es práctico: ya no hace falta reproducir el tráfico real en local para saber qué función se come la CPU o la memoria.

Cloudflare dice que trabaja en perfilado continuo, y apuesto a que ese será el siguiente paso. Mientras tanto, el valor está en combinar logs, métricas y perfiles. Quien lo haga detectará antes los problemas intermitentes que hoy se pasan por alto.

Artículos relacionados de LaRebelión

Cloudflare compra Deno: guía para preparar tus proyectos WorkersLong Polling, SSE, WebSockets y Webhooks: cómo elegir el patrón en tiempo realCómo ahorrar memoria en un anillo de hash consistente, al estilo Cloudflare

• Ingeniería de software
• Guía para migrar a Structured Concurrency final en JDK 28
• Cómo escalar Git: quórums por referencia y almacenamiento de objetos

Fuente original: infoq.com

Artículo generado mediante AI.larebelion

Kernel · Dirección de tecnología · España

«Pasar de saber que algo va lento a ver qué función lo causa, sin reproducirlo en local, es el cambio real de esta novedad.»