php-bug-catcher / bug-catcher

94%

main: 94%

LAST BUILD ON BRANCH v2.0.1

branch: v2.0.1

CHANGE BRANCH

x

Reset

• v2.0.1
• 0.1.4
• 1.1.0
• 1.1.1
• 1.1.2
• 1.1.3
• 1.1.5
• 1.1.6
• 1.1.7
• 1.1.8
• 1.2.0
• 1.2.1
• 1.2.2
• 1.2.3
• 1.2.4
• 1.3.0
• 1.4.0
• 1.5.0
• 1.5.1
• 1.5.2
• 1.6.0
• 1.7.0
• 1.8.0
• 1.8.1
• 1.9.0
• feat/mcp-server
• fix/stacktrace-display
• main
• multi-login
• selection
• tailwind
• v2.0.0
• v2.0.0-RC1
• v2.0.0-RC2
• v2.0.0-RC3
• v2.0.0-RC4
• v2.0.2
• v2.0.3
• v2.1.0
• v2.2.0
• v2.3.0
• v2.4.0

Build # 37185283151

Build Type

push

github

Committed by tito10047

Commit Message

fix(perf): a machine that cannot measure CPU has no waiting band

The collector omits `u` and `s` where the platform has no getrusage() - which
is every Windows machine - and the aggregator sums what it is given, so those
buckets arrive with `sumUser` and `sumSys` at zero. The report then computed
the waiting band as wallclock minus nothing, and "where the time went" would
have said every Windows request spent 100 % of itself waiting on the database.
That is not a small inaccuracy: it is the most confident wrong answer the
dashboard can give, on the chart whose whole point is finding the database.

`PerfTimePoint::$waitMs` and `TopPathRow::waitMsPerHit()` are now null there.
Not a guess - a PHP request that burned exactly zero microseconds of user
*and* system time does not exist, let alone a whole bucket of them, so zero
across a bucket with traffic can only mean the measurement is missing.

The CPU chart draws nothing for a window with no CPU anywhere, and the panel
says why in words. One bucket that did report is enough to draw it; the rest
contribute nothing to the band rather than all of it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Coverage Stats

16 of 16 new or added lines in 5 files covered. (100.0%)

3086 of 3276 relevant lines covered (94.2%)

20.82 hits per line