mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-08-09 08:04:45 +00:00
Claude
cc73639ae5
Backlog items 4-5 close. Both-variants-in-one-run A/B at 50k, repeated with relay order reversed: every delta flipped with the order (the second-running relay won queries and ingest latency in BOTH runs), so readers=8 / mmap_size=256MiB / temp_store=MEMORY / periodic PRAGMA optimize are all noise-level on container-class hardware. The config plumbing stays (hardware-dependent, operators should measure their own box); the example config now says so explicitly. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TtDNpayEYvJH7QuPswND3A
51 lines
2.0 KiB
Markdown
51 lines
2.0 KiB
Markdown
# Server-side SQLite knobs — A/B verdict: no winner on container hardware
|
||
|
||
**Status: closed (negative result recorded).** Backlog items 4–5 of the
|
||
relay performance campaign.
|
||
|
||
## What was tested
|
||
|
||
The knobs the campaign had previously reverted as noise-inconclusive,
|
||
re-tested under the A/B protocol — both variants in ONE relayBench run
|
||
(identical container conditions), then the run repeated with the relay
|
||
order reversed to expose order bias. 50k synthetic corpus, all four
|
||
knobs on the candidate at once:
|
||
|
||
```toml
|
||
[database]
|
||
readers = 8 # reader pool (default 4)
|
||
mmap_size = 268435456 # 256 MiB
|
||
temp_store_memory = true
|
||
optimize_interval_seconds = 15 # PRAGMA optimize between ingest and queries
|
||
```
|
||
|
||
## Result
|
||
|
||
Every observed delta flipped with run order. In BOTH runs the
|
||
second-running relay won most query scenarios and ingest latency —
|
||
regardless of which variant it was:
|
||
|
||
- run 1 (plain → knobs): knobs won 7/10 query scenarios, better ingest
|
||
p99 (8.2 vs 16.0 ms).
|
||
- run 2 (knobs → plain): plain won 6/10 query scenarios, better ingest
|
||
p50/p99/throughput (8,552 vs 8,015 ev/s).
|
||
|
||
Storage size identical (±1 MiB). The periodic `PRAGMA optimize` also
|
||
did not move the author-archive/planner-sensitive scenarios.
|
||
|
||
## Verdict
|
||
|
||
**All knobs stay off by default.** The `[database]` config plumbing
|
||
ships anyway (readers / mmap_size / temp_store_memory /
|
||
optimize_interval_seconds) because their value is hardware-dependent —
|
||
an operator on NVMe with a large page cache or a memory-constrained VPS
|
||
should measure on their own box — and `optimize_interval_seconds`
|
||
remains sensible operationally for long-running relays even without a
|
||
measurable win at 50k-fresh-database scale.
|
||
|
||
**Do not re-benchmark these on container-class 4-core hardware** without
|
||
first fixing the run-order bias: the protocol note in
|
||
`quartz/plans/2026-07-03-incremental-negentropy-storage.md` applies —
|
||
same-run A/B plus order reversal is the minimum, and anything that
|
||
doesn't survive the order flip is noise.
|