Profiling em Workers: descubra o custo da telemetria antes de reescrever a aplicação

A Cloudflare disponibilizou captura sob demanda de perfis de CPU e memória para Workers e Durable Objects, pelo painel de observabilidade ou pela CLI cf.[12] O resultado pode ser explorado em flamegraph e baixado para outras ferramentas, como pprof.[12] O recurso oferece uma forma de investigar consumo dentro da execução real, em vez de tentar explicar tudo apenas por métricas agregadas.

O que muda para quem desenvolve

Um caso apresentado pela empresa tinha P999 de memória em 133 MB, acima do limite de 128 MB, e aproximadamente 66,7% das alocações vinham de instrumentação Prometheus.[12] A equipe acreditava que a instrumentação estava desativada: os dados não eram enviados, mas parte do trabalho continuava executando e alocando memória.[12] Após remover esse caminho, o P999 reportado caiu para 118 MB.[12]

Minha leitura: uma opção de desativar exportação não deve ser confundida com ausência de custo. Se a hipótese é que um componente deixou de participar do processamento, recomendo verificar a execução e as alocações, não apenas a ausência de mensagens no destino.

Outro exemplo envolve uma transformação de JSON que duplicava trabalho já feito pela passagem de JSON.stringify.[12] A mudança tornou aquela função 2,7 vezes mais rápida, não o Worker inteiro.[12] Preserve o denominador quando avaliar a melhoria: otimizar um trecho e reduzir a latência total são resultados diferentes.

Como aplicar

Comece por uma pergunta específica, como qual função concentra alocações durante determinada operação. Selecione a versão implantada e o tráfego relevantes. O serviço precisa encontrar um isolate ativo e não cria outro apenas para gerar o perfil.[12]

Faça mais de uma captura sob condições comparáveis. Em TypeScript, disponibilize source maps para facilitar a interpretação dos nomes, conforme a orientação do anúncio.[12] Registre versão, janela e tipo de operação ao lado do artefato.

Escolha uma única hipótese e altere um trecho delimitado. Depois, repita o perfil e compare também métricas externas, como erro, latência e consumo observado. O experimento só deve ser considerado positivo se a melhora local não vier acompanhada de regressão funcional ou de deslocamento do custo para outro ponto.

Para uma suspeita sobre telemetria, compare duas configurações em ambiente apropriado: uma que deixe de exportar dados e outra que realmente retire o processamento opcional. Não assuma antecipadamente que seu código terá o mesmo comportamento do exemplo da Cloudflare.

Cuidados e limites

O perfil de memória mostra alocações realizadas durante a janela de captura, não todo o trabalho da inicialização.[12] Portanto, não use uma janela curta como retrato completo da memória já retida.

A sessão é iniciada explicitamente, e o profiling contínuo é descrito como desenvolvimento futuro.[12] Eventos raros podem escapar à coleta atual.[12] Para Durable Objects, é possível direcionar a captura ao objeto pelo nome; uma amostra de Worker não representa automaticamente a frota inteira.[12]

Use o perfil como evidência localizada. A melhor otimização é aquela que resolve um custo demonstrado e preserva o comportamento, não a que produz o flamegraph mais bonito.

Fonte

[12] Fonte: Cloudflare Blog