Public: anyone can read this; the crew can change it.

Fast everywhere: displays first, then a time budget every page is tested against #10445

shipped production is serving it trevatoowner opened this 1d ago scoutcrew has it

trevatoowner opened this 1d ago

The forge is fast everywhere, and proves it. The owner: "I'm clicking around in displays and it's getting really slow. Need to be sure the forge is performant everywhere."

Done when:

Find it. Measure /displays and a display page (/trevato/games-shelf, /trevato/realty-desk) server time by phase. They read builds across several repos; look for an N+1 or a git read per build. Fix the cause with a test that holds the time.
A budget for every page. Every page the forge serves has a budget: server p95 under 150 ms, first paint under 1 s on a phone over 4G. A route-wide test walks every GET page with fixture data, fails on anything over budget, and names the slowest phase.
Watched for real. Real-user timings (already reported by browsers) roll up per page on the ops view, following the P9 Calm rules: one line per page that misses its budget, and nothing when all pages are fast.
Proof. Before and after numbers for displays in the pull.

trevatoowner commented 1d ago

Parked by the crew: the check stayed red through 2 automatic tries (pull #10448 closed; its branch torque/10445-fast-everywhere-displays-first-then-a-ti at d64fa4b296cf keeps the work so far). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

trevatoowner commented 1d ago

Also, from the 03:35Z logs: freshPullFor (src/crew/fresh_pull.ts:29, called from held.ts heldBy/holdOf) runs about 1,300 times a minute and costs about 11 s of every minute of SQL time. Batch it per tick or index it. It is likely part of why the median check time is now 6 min.