Timeline

quarry could not answer two questions about its own behaviour. A render time was printed in the page footer and discarded, so a 4.24s files page was visible only to whoever loaded it and read the footer. Subprocess load was visible nowhere: a warm loop once ran 134 concurrent `zit ls --long` against the same hash, load average 546 on 14 cores, and /fleet said "all healthy" throughout.

/fleet/ops, site-admin only. Slowest routes by p95 — a mean hides the tail, and the tail is the thing worth finding. Store subprocesses rolled up per verb, with the number that actually mattered: how many run at once, and the peak, which outlives the incident. Recent renders with ops time and the zit time inside it.

Instrumented at the two seams that cover everything: the ops registry, which every page's data crosses, and the outermost middleware, which is the only place the template's own cost is known — the footer's breakdown is assembled before the template runs, so a page can never report the time it spent rendering itself.

Datastar with no no-script path, deliberately: an internal dashboard that cannot move while an operator watches a fleet index is worth much less than one that can, and no consumer depends on it. The op behind it is registered and versioned like any other.

The rings are small and in memory. This is the snapshot; history belongs in the analytics store behind obs.Sink, which is an interface with a no-op default so the persistent implementation can be cgo without the request path importing it. closed check-in: 022966bc05 user: dmestas tags: fleet-ops

zit ls --long adds size, permission and text/binary, and the last of those reads every listed blob. On a large store the annotated forms cost ~18ms per file where the plain two-field listing costs ~0.09ms: measured on tcl, 0.20s plain against 38s for --size and 41s for --long. The cost scales with the STORE, not the listing (filed as zit#148).

Four callers read only .Name and threw the rest away: the About marker scan, a root check-in's file set, the doc index, and CI's file list. They use LsNames now, which runs the plain listing and caches it beside the annotated one.

The tree page and its warm still need the columns they display, so they are unchanged; that cost is the upstream issue's to fix. check-in: 78db482057 user: dmestas tags: trunk

The poll loop ran 'go cli.Ls(ctx, tip)' on EVERY tick as a bare goroutine whose result was discarded. On a store where that call takes seconds the next tick started another before the last finished, and across a fleet they compounded.

Measured: 134 concurrent 'zit ls --long', all against the SAME hash, under one server, load average 546 on a 14-core machine.

The listing is immutable per version, so it needs computing once per version. Now it skips when the tip has not moved and when a warm is already in flight. check-in: a3475428ac user: dmestas tags: trunk

warmReads and indexTree each spawn several zit subprocesses — ls, ls-under, a cat per file, an archive — and on a store tcl's size each takes seconds. They were launched as bare goroutines from every round that moved the tip, so the next round started another set before the last had finished and they stacked.

Measured on the demo fleet: 43 zit children under one server, three of them the same ls against the same hash, load average 546 on 14 cores.

A warm pass already running IS the warm pass. CompareAndSwap claims the slot and the winner clears it on the way out; a round that finds one in flight skips rather than piling on. check-in: 0325ba4a2c user: dmestas tags: trunk

Accepting an already-accepted landing wrote another state reply, and four stacked up on one record before it was noticed.

Two causes. The guard read state from the INDEX, which lags the store by an ingest round, so a second press inside that window saw 'open' and passed. And zit does not refuse the write either — an already-contained branch still gets a reply saying 'accepted', with 'nothing to merge' in the body.

So: fold first, re-read, then decide. A settle is deliberate and rare and can afford one ingest round to know what it is settling. And already-settled now succeeds writing nothing, because that is the end state the caller asked for; an error made a double press look broken when the landing was exactly as they wanted.

Proven against a running server: three accepts in a row leave one 'accepted this' reply and no 'nothing to merge'. check-in: f102c4c7ec user: dmestas tags: trunk

A border-right per item is the single-row idiom, and it breaks the moment the strip wraps — the item ending a row keeps a divider that lands against the container edge, the last item overall has none, and nothing rules between rows. Measured live at 390px the activity strip is three rows, so wrapping is the normal case.

Letting the container's colour show through a 1px gap draws every divider the layout actually needs, vertical and horizontal, with no rule needing to know where a row ends. closed check-in: 76dc2b8d96 user: dmestas tags: pager-shape

The glyph was always centred; the boxes were not. The current page is a span and took 0.5rem of padding with no border, every other page is an anchor and took 0.6rem plus a 1px border — 48px against 53.2px for the same digit.

So the highlight changed size as the pointer moved along the row, and a number sitting still inside a box that grew around it read as though it had slid off centre. Padding and border are stated once for both now.

Measured: every cell 53.2x32.7 at desktop, 37.2 wide at 390px, glyph centred in all of them. check-in: 2ae6328950 user: dmestas tags: pager-shape