Cloudflare leva profiling de CPU e memória para Workers em produção

O que muda na caixa de ferramentas do Workers

A Cloudflare anunciou em 9 de outubro de 2026 o profiling sob demanda de CPU e memória para Workers e Durable Objects em produção, segundo reportagem da InfoQ. O recurso gera flamegraphs interativos pelo dashboard de Workers Observability ou pela cf CLI, permitindo investigar gargalos sem depender só de logs e métricas agregadas.

No flamegraph, seções mais largas indicam funções responsáveis por uma fatia maior do tempo de CPU ou das alocações de memória amostradas. Os perfis também podem ser baixados para análise offline. Para quem já perdeu tempo tentando reproduzir localmente um pico de latência que só acontece sob tráfego real, essa é a mudança prática mais relevante.

Como o profiling funciona num isolate já rodando

A diferença central é que o profiling mira um isolate já em execução, não um novo processo iniciado para o teste. Isso permite examinar código rodando sob tráfego de produção real, em vez de simular carga em ambiente de desenvolvimento.

A engenharia por trás disso precisa lidar com a infraestrutura distribuída da borda da Cloudflare, onde um mesmo script pode ter múltiplos isolates espalhados por data centers e máquinas físicas diferentes. Uma requisição de profiling precisa identificar a versão do Worker solicitada e localizar um isolate ativo adequado para capturar.

Para CPU, o runtime inicia um profiler do V8 que amostra pilhas de chamada em intervalos de um milissegundo. Ele libera o lock do isolate enquanto as requisições continuam sendo processadas normalmente, e só o readquire para parar o profiling e coletar os resultados. Na prática, isso significa observar execução ao vivo sem suspender o processamento de requisições durante a captura.

Há duas condições práticas para o recurso funcionar bem: o alvo precisa receber tráfego suficiente durante a janela de captura, e devs em TypeScript↳TypeScript23 conteúdosTypeScript: ReadonlyArrayDev (Back & Front) · jun 2019Onde usar ANY no TypeScriptDev (Back & Front) · out 2025Tudo sobre o Node rodar TypeScript nativamente!Dev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → devem habilitar source maps para que os nomes de função apareçam de forma legível no flamegraph.

CPU e memória respondem perguntas diferentes

Profiling de CPU amostra pilhas de chamada para revelar onde o tempo de execução está sendo gasto, ajudando a identificar funções caras, computação redundante e oportunidades de otimização. Profiling de memória, por outro lado, destaca alocações associadas a funções, ajudando a achar código que cria objetos em excesso ou contribui para pressão de memória.

Uma função pode consumir CPU significativa sem alocar muita memória, enquanto outra pode gerar alocações substanciais sem dominar o tempo de execução. Examinar o perfil adequado para cada sintoma ajuda a restringir a investigação ao gargalo correto, em vez de adivinhar entre dois tipos de problema que parecem iguais de fora.

Durable Objects exigem roteamento específico

Durable Objects recebem suporte adicional para profiling de uma instância nomeada específica, útil ao investigar problemas ligados a workloads stateful. O desafio extra é que esses objetos são stateful e podem se mover entre localizações físicas ao longo do tempo.

Para resolver isso, a Cloudflare roteia a requisição de profiling para a máquina que hospeda o objeto específico no momento da captura. É um detalhe de engenharia que importa na prática: sem esse roteamento dinâmico, profiling de Durable Objects seria inútil em qualquer cenário real de produção distribuída.

O case interno: de onde vêm os números

A própria Cloudflare usou o recurso internamente para identificar computação e consumo de memória desnecessários antes de liberá-lo publicamente. Dois achados ilustram o tipo de problema que o profiling expõe:

• Profiling de um Worker com binding R2 revelou um replacer JSON recursivo que percorria dados aninhados repetidamente, fazendo trabalho redundante; corrigir a implementação deixou a função, segundo a Cloudflare, 2,7 vezes mais rápida.
• Outro perfil expôs uma chamada de métricas duplicada e desnecessária, responsável por cerca de 1% do tempo de CPU.

No lado da memória, o profiling identificou instrumentação Prometheus parcialmente desabilitada que ainda consumia memória substancial. A Cloudflare afirma que remover o código remanescente reduziu o uso de memória no percentil 99,9 do Worker de 133 MB para 118 MB, trazendo-o para abaixo do limite de 128 MB da plataforma.

Como se compara a Chrome DevTools e pprof

O recurso complementa ferramentas já estabelecidas em vez de substituí-las. Chrome DevTools oferece profiling local de CPU, útil durante desenvolvimento, mas reproduzir tráfego e dados de produção localmente costuma ser difícil ou impossível. O pprof, amplamente usado em Go e outros fluxos de profiling suportados, oferece análise offline poderosa de perfis, e a própria Cloudflare permite examinar os perfis baixados com pprof.

O diferencial da Cloudflare é a capacidade de iniciar profiling contra Workers e Durable Objects já em execução, através da interface operacional que a plataforma já oferece. Somado a logs, métricas e tracing distribuído, o profiling ajuda a apontar exatamente qual função é responsável por um comportamento que essas outras ferramentas já sinalizaram como lento ou custoso.

O que ainda fica em aberto

Captura sob demanda não é monitoramento contínuo. Janelas curtas de profiling podem não capturar problemas intermitentes, e perfis de heap registram alocações só durante a captura, sem dar um retrato completo da memória retida ao longo do tempo. A Cloudflare diz estar trabalhando em profiling contínuo, o que poderia facilitar a investigação de problemas raros sem precisar antecipar quando eles vão acontecer.

Para quem roda Workers no Brasil

Para times brasileiros que já usam Cloudflare Workers em produção, principalmente em cenários edge-first com latência crítica para usuários no país, a mudança prática é sair do modo "aumentar logs e torcer" para isolar a função responsável por um gargalo sem reproduzir o cenário localmente. Isso importa especialmente em arquiteturas com Durable Objects stateful, onde reproduzir um bug de produção fora do ambiente real costuma ser quase impossível.

Vale testar o fluxo primeiro em um Worker de baixo risco, capturando um perfil de CPU via cf CLI durante um pico de tráfego real, antes de confiar na ferramenta para diagnosticar um incidente sob pressão. E para quem já usa pprof no stack Go, a compatibilidade de exportação reduz o atrito de incorporar o profiling da Cloudflare ao fluxo de observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → que já existe.

Fonte: InfoQ