feat(profiling): internal metrics for overhead#3616
Conversation
This comment has been minimized.
This comment has been minimized.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3616 +/- ##
==========================================
- Coverage 62.21% 62.11% -0.11%
==========================================
Files 141 141
Lines 13387 13387
Branches 1753 1753
==========================================
- Hits 8329 8315 -14
- Misses 4260 4273 +13
- Partials 798 799 +1 see 3 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
Benchmarks [ profiler ]Benchmark execution time: 2026-02-03 19:57:47 Comparing candidate commit aed7a13 in PR branch Found 2 performance improvements and 3 performance regressions! Performance is the same for 24 metrics, 7 unstable metrics. scenario:php-profiler-timeline-memory-with-profiler
scenario:php-profiler-timeline-memory-with-profiler-and-timeline
|
…ddprof_upload` for current profile exported Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
I was reviewing this and made a few additions that build on your work in #3618, let me know what you think |
Description
This is an alternative to #3591. Instead of putting the time we spend stack walking into the timeline and flamegraph, we instead aggregate it into counters, which we emit into internal metrics. This addresses some of the concerns I received about that PR while still providing something we believe is useful: the ability to understand our overhead for a specific profile. This internal metric could be re-exported in the future if we desire to do per-organization or other type of aggregation, for example, to determine which customers are hitting the highest amounts of overhead.
In addition to collecting CPU time walking the stack, this also aggregates CPU time spent in our two background threads,
ddprof_timeandddprof_upload. The former is a bit of a misnomer because it also aggregates CPU samples, it doesn't just track time.Manually verified it's working (practically idle service), this is on a slightly older version of the PR so it looks a little different now:
Reviewer checklist