R-267: the Configuration page, measured — 26.2s to ~10s, and what is left
gates / gates (push) Successful in 22s

Reported as 'almost minutes'. The guess that it hashes artifacts on page load DOES NOT HOLD and the
code already said so: Gitea stores the sha and the hub reads it as metadata. The cost was latency x
count, fixed in three legs (hub v0.100.0-0.100.2), each found by refusing to accept a number that
did not match the arithmetic.

Measured 26.2s -> mean 9.85s over 8 samples (min 5.13, max 18.13). The remaining dominant cost is the
package SEARCH, 0.20-3.8s per dropdown depending on load, which concurrency does not help; 16
concurrent file-metadata calls take 0.58s by comparison.

EVERY NUMBER IS CONTAMINATED and the row says so: taken on DooPlex at load average 7-11 while this
same session was building images, running two Go suites and baking a golden. The same search measured
3.8s in-cluster and 0.44s from the host ninety seconds later. Re-measure on an idle box.

Both operator proposals answered on the measurement rather than deferred to: pruning artifacts helps
sub-linearly (only 50 versions exist) and is worth doing for its own sake; storing the hash in the
hub DB is NOT recommended, because Gitea is already the store and a copy would be a second source of
truth the operator reads to confirm a vouch. The lever that would work — an in-memory cache with a
TTL — is left OPEN because it trades dropdown freshness for speed, which is an operator decision.
This commit is contained in:
2026-08-08 18:03:00 +02:00
parent 047e296ad1
commit 1c14b91d6f
2 changed files with 7 additions and 0 deletions
+5
View File
@@ -91,6 +91,11 @@ being readable.*
it writes PASS/FAIL to `/var/log/felhom-store-postboot-check.log`. On PASS, 34 GB comes back. *(R-209a)*
- **Backup scripts on DooPlex are unversioned host state** *(R-231)*, and the instruction-file
follow-ups each need a decision rather than an edit *(R-229, R-230)*.
- **The Configuration page: 26 s → about 10 s, and not finished.** It was never hashing anything —
the hashes are already stored and just read. It was making 42 calls one after another. What is
left is a single slow Gitea lookup per dropdown; making it instant means holding a short-lived
copy, which trades freshness for speed and is your call. **Numbers were taken on a busy box and
swing 3×** — worth a re-check when it is idle. *(R-267)*
- **Our build-check alarm has one gap left.** A run that hangs is now cut off after five minutes and
the mail says how long it took — but **whether the alarm fires at all when the machinery kills a
run outright is still unverified**, and we have not claimed otherwise. *(R-265)*