php-bug-catcher / bug-catcher / 37436952124

94%

push

github

feat(perf): a cron box gets a row that is not an alarm about waiting

Apdex asks one absolute question - did the caller wait more than 500 ms -
and T is pinned there because T and 4T both have to land on histogram bin
edges or the score starts interpolating. The only exact pairs on that
scale are (25, 100), (250, 1000) and (500, 2000), so there is no
cron-scale T. On a machine whose whole job is messenger consumers and
import loops the cell therefore reads 0.00 in red for ever, whatever the
machine is doing - the one failure ConjunctiveThresholdPolicy's docblock
warns about.

The cells that can answer a worker were already built and already opt-in:
PerfRegressions judges a route against its own day-of-week baseline, and
PerfThroughput is the one number that goes *down* when something breaks.
What was missing was a way to say which row a project gets, since
perf_status_list_components is installation-wide - dropping Apdex for the
cron boxes would drop it for the websites too.

So Project::$perfProfile (Enum\PerfProfile, a select beside the existing
perfEnabled checkbox) picks between perf_status_list_components and the
new worker_status_list_components, and StatusList::componentsFor() is the
only place both questions are asked. perfEnabled keeps its meaning: the
workload chooses which performance row, never whether there is one.

The column is nullable and null is Web, so an existing installation
upgrades into the row it already had with a migration that
migrations:diff generates unedited - a NOT NULL column would need the
DEFAULT written in by hand, which is how project.perf_enabled ended up
NOT NULL DEFAULT 0 on a live database.

PerfRegressions moves to col-span-2, the width of every other number on
the row, so the worker row adds up to the same twelve columns as the web
one. Nothing in the default web row changes.

ProjectWorkloadTest opens the admin form, which phpunit never rendered
and the skeleton e2e stops short of: a ChoiceField over enum *ob... (continued)

27 of 27 new or added lines in 4 files covered. (100.0%)

3311 of 3515 relevant lines covered (94.2%)

23.72 hits per line