Repository navigation
Check the performance of all Cloudflare binding instrumentations #24778
Description
Activity
We profiled a production Worker (~44M req/day, mostly small POST ingest) with Workers on-demand profiling, using
@sentry/cloudflare10.66 andtracesSampleRate: 0. The largest costs were per-requestinit()and OpenTelemetry tracer registration (fixed bycacheClientin v11, thanks) and request body capture (now gated bydataCollection.httpBodies).One cost that remains in 11.6.0 with tracing off:
wrapRequestHandlerWithInitstill buildshttp.serverspan attributes on every request (httpHeadersToSpanAttributes→filterKeyValueDataover all headers, plusaddRequest, culture context), even when the span can't be sampled. In our heap profiles those two functions were about 9% of sampled allocation bytes. It looks like the same pattern #24655 fixed for Durable Object SQL: skip building attributes when the span won't be sent.
Description
A SQL-heavy Durable Object workload showed a large CPU regression in
@sentry/cloudflare10.61.0, caused by instrumentation work on everystorage.sql.exec()call. This showed that the per-call cost of our Cloudflare instrumentations was not checked in a structured way.Go over all instrumentations in
@sentry/cloudflareand check their CPU cost, withtracesSampleRate: 1and withtracesSampleRate: 0:(follow up to #24655)