writeonce/docs/plan
shoney.arickathil 6183a67dfc perf(db): group commit measured — ~2.9x durable write throughput, T5
databasev2 4 part A, task 5.

Controlled before/after — same machine, same workload (wmix 4000 32),
same build except db.c and vm.c, two runs each interleaved:

- per-statement barrier: 2213 / 2177 ops/sec, p50 7183 / 7251us
- group commit:          6216 / 6525 ops/sec, p50 3458 / 3444us
- ~2.9x throughput, ~2.1x lower p50

The full campaign confirms it a second way: s1 takes the inline path and
commits per statement BY DESIGN, so within one build the shard configs are
batching-off vs batching-on — 1467 -> 5117 ops/sec, mean batch 1.0 -> 5.43,
peak 1 -> 57. 3.5x, agreeing with the 2.9x above.

Recorded honestly:

- the BEFORE p99 is at the histogram ceiling (hist_add clamps at 20000us
  and both runs pinned there), so the true figure is >=20ms and unknown.
  The improvement is AT LEAST 2.3x; the old p99 was off the instrument
- durable.sN.mixwrite went 480 -> 492 ops/sec, i.e. UNCHANGED. That was
  the spec's original payoff metric and correcting it was part of the
  brainstorm: mix performs 20 writes at C=4, mean batch 1.01. A workload
  that never has two writes in flight cannot be helped by batching them
- seed is likewise unchanged: a serial writer has nothing to batch with
- so the payoff is real but CONDITIONAL — it appears where concurrent
  durable writes fan into the owner shard, and nowhere else

Two traps recorded in perf-targets §6:

- do not benchmark durability on /tmp: it is tmpfs here, where fdatasync
  is free. The same run reported 195000 ops/sec at p50 1us there against
  2200 at p50 7200us on ext4 — no barrier to amortise, so the measurement
  measures nothing. db-bench keeps its stores under bench/ for this reason
- the record count is not the update count: 7755 records for 4000 updates,
  because hist_dump and the done-marker are themselves durable inserts

- FIXED a regression I introduced in T4: master's committed baseline is
  FULL mode (N=20000, crash_reps=3, msg_n=200000) and I had overwritten it
  with quick-mode values. Regenerated from a full campaign; the full run
  now passes 106 checks 0 failures against it
- gate still bites: sN wmix ops_sec -70% -> FAIL on exactly that metric

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-28 09:54:52 +02:00
..
compiler docs: audit all markdown against the code, fix findings, flatten status folders 2026-08-26 19:20:22 +02:00
exploration docs(databasev2): third track — the database beyond RAM, with per-table storage modes 2026-08-26 20:52:48 +02:00
oop-vm Merge branch 'master' into chat-ws-lifecycle 2026-08-27 23:11:49 +02:00
discarded.md docs(databasev2): third track — the database beyond RAM, with per-table storage modes 2026-08-26 20:52:48 +02:00
learnings.md docs: status board moved to docs/stories/00-status.md 2026-08-21 10:07:20 +02:00
perf-targets.md perf(db): group commit measured — ~2.9x durable write throughput, T5 2026-08-28 09:54:52 +02:00