Repository navigation
perf: unmeasured leads from the whole-repo audit behind #457 #458
Description
Performance leads the static audit behind #457 found and left without code, because none is measured end to end. Each needs an interleaved A/B (or a hold-time measurement) before a change; the expected effect below is an estimate.
| Where | Lead | What to measure |
|---|---|---|
store/s3/s3.go Metas |
GETs labels.json for every record, though only templates carry labels: one extra 404 GET per checkpoint on every GET /v1/checkpoints and hourly TTL sweep |
S3 request count and listing latency at a few thousand checkpoints |
server/server.go checkpoint claim on a shared S3 store |
An unknown checkpoint still probes every peer, which answer from the same bucket; a genuine miss waits for every peer (up to the 1 s probe timeout) before 404 | miss latency with and without the prober on a shared store |
pool/archive.go wakeArchived |
Deletes the consumed archive checkpoint (several sequential S3 round trips) and drops the tombstone while holding the claim's transition, before the relay gets its socket; the pre-commit marker already makes the delete retryable | archived-wake latency, delete inline vs in the background |
store/peer/move.go, store/sparse.go |
Every live-move round hashes each non-zero chunk on both sides; the final round's hashes sit inside the guest's pause | final-round pause with and without the hash on the 2xlarge tier |
silkd/src/server.rs feed_client |
Each stdin/data frame decodes into a fresh buffer (up to 768 KiB for a 1 MiB port chunk) because the decode takes the scratch | port-forward throughput and allocation rate |
silkd/src/find.rs fs_replace |
replace_all over up to 8 MiB runs on the tokio worker; a 1-vCPU guest stalls other relays for that pass |
relay latency during a large replace |
pool/telemetry.go egress decisions |
Each decision appends a usage line (and an audit line with audit_log) under the node-wide journal lock before the response header |
request time to first byte under load |
pool/liveness.go onVMChange |
Each VM-down/deleted event walks every claim under the manager lock (no VM-name index) | lock hold time at 20000 claims under release load |
pool/claim.go admission at the cap |
Concurrent claims at the last free slot each pop a warm VM; all but one fail at finalize and their VMs are destroyed | a burst at the cap: refill clones per refused claim |
pool/template.go promoted-template claim on S3 |
Each claim GETs meta.json even when the generation is cached (two for a checkpoint claim) |
promoted-template claim p50, S3 vs dir store |
Activity
CMGS commentedon Nov 5, 2026
Progress on 2026-11-05.
Measured and done:
Metaslabels GET: store/s3: read labels only on the template store when listing #461 (1 LIST + 2N GETs → 1 LIST + N GETs for checkpoint listings and reconcile).fs_replacereplace_allon the worker: silkd: compile find and replace patterns and run replacements off the runtime #462. Pattern compile and replace both moved to the blocking pool; the worst runtime stall under a\w{1,200}find fell from 47-70 ms to 2.4-2.8 ms.onVMChangeclaim walk: pool: find a VM event's claim through a VM-name index instead of a scan #459 (VM-name index; 10 / 67 / 340 µs at 1k / 5k / 20k claims → ~60 ns).Split into issues, each with its measurement and trigger:
wakeArchivedinline delete: pool: an archived wake waits for the consumed checkpoint's store delete #464.Still open here, not measured yet:
feed_clientdecode buffer (silkd). A measurement ofwrite_frame's per-frame write buffer (0.1-0.3 µs) was taken by mistake. It says nothing about this lead, the fresh decode buffer per stdin or data frame on the read side.meta.jsonon S3 even when the generation is cached.CMGS commentedon Nov 5, 2026
The remaining four leads, measured on 2026-11-05. All 10 leads now have an outcome, so this issue closes.
feed_clientdecode buffermeta.jsonGET on S3Earlier on this issue: #459, #460, #461 and #462 merged; #463 and #464 opened.