Align performance budgets with binary units and measured workloads #90
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem and evidence
The build plan has mismatched units and incomplete workload definitions. Its failing metric says cold JavaScript ≤120 KiB (122,880 bytes), while the older table still says ≤120 KB (docs/PLAN.md:377, 390-401); docs/UI.md:84 uses KiB. The 50 MiB/s log target is stated alongside a production 256 KiB receive window and 6 ms CREDIT coalescing; a one-window-per-credit path can provide at most about 41.7 MiB/s before RTT and processing. Logs measured 6–13 MiB/s in the 306-per-engine workload at load1 roughly 25–34. The 60 fps log target has no frame-interval percentile or long-task rule; at 10k lines/s, browser frame p99 was 216.7 ms at load1 24.84 and 33.4 ms on a repeat at load1 8.29. The 15 MiB standalone RSS limit also lacks warm/cold and inventory occupancy.
Evidence and traces: browser-cold-results.json, browser-busy-loaded-timeline.json, idle-summary.json. This is a spec/gate issue; those artifacts are the supporting measurements rather than one dedicated flamegraph.
Recommendation
Make one documentation/gate correction: use consistent binary units, define RSS occupancy/warm state, define 60 fps with frame-interval and long-task pass conditions, and state how the 256 KiB / 6 ms product credit policy is evaluated against the unchanged 50 MiB/s simultaneous gate. Keep 120 KiB as the cap and do not lower 50 MiB/s based only on unshaped runs; calibrate only on the perf-test VM as PLAN requires.
Payoff, effort and risk
Expected gain: unambiguous, reproducible pass/fail results and no gate that certifies a different receive-window policy from production. No direct product throughput gain is claimed by the documentation change.
Quick win vs deeper change: unit cleanup and workload definitions are estimated at ≤½ day; updating evaluator metrics and calibrating on the perf-test VM is estimated at 1–2 days.
Risk: low to medium; wording changes can hide failures if thresholds are silently relaxed. Preserve existing hard limits until an owner-approved calibration.
Priority: Now (≤1 day for the spec correction).
2026-10-04 owner decisions: Matches performance-first failing gates, code/tests as the spec, and the 500-host / 20,000-container scale target. The infraternal agent RSS budget must stay tied to the audit. Related: #55 for settled architecture/contract documentation and #53 for gate operation.
Report: perf-audit report
Source: perf-audit 2026-10-04
Starting issue work on branch
gate-tooling-nowat base069059d31fcd91366e76072e6be4871c01e5cde6.Scope: make the supply-chain check compare notices without rewriting the tracked file and resolve the
jitidiscrepancy; repair the perf gate's container search and lazy log selectors; align performance budget units/workload definitions and document each source from the perf audit. I will run onlyINFRATERAL_VERIFY_RUN_ID=gate-tooling-now scripts/verify fastand report its exact output plus final tree status.Finding:
scripts/perf/metrics.mjsalready enforces the 120 KiB route cap (122,880 bytes), binary MiB RSS/throughput limits, and a 25,000,000-byte binary-size cap.docs/PLAN.mdstill contains decimal120 KBand25 MBlabels and does not define the log frame/long-task pass condition or the RSS fixture occupancy. The audit reports standalone RSS of 15.465 MiB in the quiet release sample and 18.684 MiB with 612 fixtures; the existing 15 MiB cap stays unchanged and needs an explicitly warm, zero-fixture definition. The concurrent benchmark uses a 4 MiB log receive window; product defaults are 256 KiB and 6 ms, whose one-window-per-flush ceiling is about 41.7 MiB/s before RTT/processing. I will document this as a benchmark-vs-product-policy gap and preserve the 50 MiB/s cap pending a perf-test-VM A/B.Finished issue #90 on
gate-tooling-now.Head:
459046794cd600c1b890472064b69c76b50c99baThe perf budget docs now use binary units and identify each cap's source/workload. They define warm idle RSS with run-owned fixture occupancy, log-frame p99 and >50 ms task criteria, and distinguish the 4 MiB benchmark receive window from the product's 256 KiB / 6 ms policy. The 50 MiB/s simultaneous cap and all other hard thresholds remain unchanged. No perf-test-VM A/B was run; the requested gate was
fastonly.Fast verification output (verbatim; command exited 0):
Bun audit reported one low
cookieadvisory as report-only.git statuswas clean after verification.