php-bug-catcher / bug-catcher / 37325658835

94%

main: 94%

push

github

feat(perf): the slow route is in the table, and says how slow

Two things stopped the heaviest-routes table from answering the question a
console-heavy project asks it.

The limit cut by traffic. `aggregateRows()` ordered by `SUM(hits)` and took
twenty-one rows; the sort the page asked for was applied to the survivors in
PHP afterwards. For a cron host that is the wrong twenty: its traffic is
hundreds of routes called once each, so the slow one was never among the
busiest and the table that was meant to show it could not. Worse, with every
row on one hit the tie had no tiebreaker, so MySQL was free to return a
different twenty on each re-read - a Live Component that flickered between
unrelated rows. The sort now goes into the `ORDER BY`, with the grouping
columns after it so two reads of one window agree. `PerfTopPathSort::P95` is
the exception and stays in PHP, because a percentile of percentiles is not a
percentile: it is estimated from the bins after they are summed, so that table
really is the slowest *of the busiest* - now the only one of which that is
true, which is what the truncation line underneath it says.

And nothing showed how slow. `EDGES_MS` ends at sixty seconds and bin fifteen
is unbounded, so `PercentileEstimator` honestly answers "at least a minute" for
anything past it - an eighteen-minute cron job reads a p95 of exactly 60000 and
is indistinguishable from a sixty-one-second one. The exact figure was already
in the database: `max_duration` is selected, aggregated with MAX and carried
into `WindowAggregate` - and then read by nothing at all. It is now a
`Slowest run` column and a sort of its own. The bins are untouched on purpose;
they are a wire format shared with the collector and changing them is a
migration of stored data.

`_docs/performance.md` gains what a console route is, and why renaming one is
an identity reset rather than a loss: seven days without a baseline, console
regressions out of `min_hits` reach, old records that... (continued)

42 of 42 new or added lines in 3 files covered. (100.0%)

3285 of 3489 relevant lines covered (94.15%)

23.82 hits per line