Repository navigation
Check the performance of all Cloudflare binding instrumentations #24778
Description
Description
A SQL-heavy Durable Object workload showed a large CPU regression in @sentry/cloudflare 10.61.0, caused by instrumentation work on every storage.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/cloudflare and check their CPU cost, with tracesSampleRate: 1 and with tracesSampleRate: 0:
- Durable Object handlers and storage (SQL, KV, sync KV, alarms)
- Worker handlers (fetch, scheduled, queue, email, tail)
- Bindings (D1, R2, queue producer, service bindings and DO stubs, Workers AI)
- Agents
- Workflows
(follow up to #24655)
Activity
linear-code commentedon Sep 28, 2026
JS-3827
anirudhsama commentedon Oct 9, 2026
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.JPeer264 commentedon Oct 12, 2026
Thanks for the insights - also great to hear that
cacheClientis doing its part here. We'll keep an eye on it when we implement it. We don't have an estimate on when we start yet, but I'll try to prioritize that a little higher in the backlog.