Cloudflare anunció la disponibilidad del perfilado bajo demanda del uso de CPU y memoria para los servicios Workers y Durable Objects, de modo que los desarrolladores pueden recopilar perfiles del propio entorno de producción y visualizarlos como gráficos de llama interactivos. La función permite identificar las funciones que consumen tiempo de CPU o asignan la mayor cantidad de memoria, en lugar de depender únicamente de los registros y las métricas agregadas.
El perfilado puede iniciarse desde la página Workers Observability del panel de Cloudflare o mediante la interfaz de línea de comandos. El desarrollador especifica el tipo de perfil, CPU o memory, y la duración de la recopilación, y también puede seleccionar distintas versiones del Worker. Una vez finalizada la sesión, puede consultar el gráfico interactivo y descargar el archivo de perfil para analizarlo con otras herramientas.
¿Qué muestran los gráficos de llama?
Cada rectángulo del gráfico representa una llamada a una función, mientras que su anchura refleja la cantidad de tiempo de CPU o memoria asociada a ella. Se puede hacer clic en las funciones para ampliar el enfoque sobre ellas, o utilizar la vista de tabla para ordenar los resultados según el número de muestras. Cloudflare recomienda capturar más de un perfil y buscar las funciones más anchas, además de activar los mapas de origen en los proyectos de TypeScript para que los nombres de las funciones no aparezcan de forma ambigua.
El perfilado requiere seleccionar una versión publicada que reciba suficiente tráfico; el servicio no crea un aislamiento nuevo con fines de medición, ya que el objetivo es observar la ejecución real en producción. Se puede utilizar el siguiente comando para capturar un perfil de CPU de cinco segundos:
cf workers versions profile latest --worker-id "$WORKER_ID_OR_NAME" --duration-ms 5000 --profile-type cpu > worker-cpu.pprof
Resultados prácticos presentados por Cloudflare
Cloudflare utilizó la herramienta para analizar un Worker que implementa el enlace con R2. El perfilado mostró que la función genericR2JsonReplacer volvía a recorrer un árbol JSON durante la ejecución de JSON.stringify, lo que provocaba que un valor anidado se procesara cinco veces en algunos casos. La corrección hizo que la función fuera 2,7 veces más rápida. El perfilado también reveló una llamada repetida a metrics, y almacenar el resultado y reutilizarlo fue suficiente para reducir el consumo de CPU.
En otro caso, uno de los Workers superaba el límite de memoria de 128 megabytes: el consumo P999 alcanzaba aproximadamente 133 megabytes y provocaba errores de “Exceeded Memory”. El perfil de heap mostró que el código de Prometheus responsable de aproximadamente el 66,7 % de las asignaciones seguía ejecutándose parcialmente, pese a que se creía que estaba desactivado. Tras eliminar por completo la ruta de código, el P999 descendió de 133 a 118 megabytes, mientras que el P50 bajó de 70 a 54 megabytes.
¿Qué cambia en la práctica?
La función proporciona a los equipos de desarrollo una visibilidad directa de la ejecución de Workers en sus condiciones reales, donde el tráfico y la distribución de los aislamientos pueden diferir del entorno de desarrollo local. La plataforma gestiona la complejidad de distribuir Workers entre varios centros de datos y dispositivos, mientras que, en Durable Objects, el desarrollador puede especificar el objeto por su nombre para obtener un perfil del aislamiento concreto que lo ejecuta.
El mecanismo de ejecución mantiene la recepción de solicitudes durante la recopilación; el bloqueo del aislamiento solo se mantiene al iniciar y detener el perfilado, y después las muestras de CPU se recopilan con un intervalo de un milisegundo durante el periodo especificado. Durable Objects, por su parte, aprovecha su naturaleza con estado para dirigir la solicitud de perfilado al aislamiento y al propietario del objeto especificado.
Limitaciones y próximo paso
El perfilado no se inicia automáticamente, por lo que la sesión puede pasar por alto periodos breves o poco frecuentes en los que se produce el problema. El perfilador de memoria también muestra únicamente las asignaciones realizadas durante la ventana de medición y no necesariamente capturará el consumo derivado del inicio. Cloudflare afirma que está trabajando en el perfilado continuo, que recopilará muestras automáticamente y permitirá consultarlas posteriormente desde el panel de control.