Skip to content

Exp 162: sustained concurrent reads + pool-cap re-test (paired run)#159

Open
danReynolds wants to merge 1 commit into
mainfrom
exp-162-concurrent-reads-pool-scaling
Open

Exp 162: sustained concurrent reads + pool-cap re-test (paired run)#159
danReynolds wants to merge 1 commit into
mainfrom
exp-162-concurrent-reads-pool-scaling

Conversation

@danReynolds

Copy link
Copy Markdown
Owner

First experiment executed under the paired-measurement rule (#158): the measurement and the implementation it unlocks, one run, one PR, both results.

Hypothesis

The signal map carried "a long-running concurrent-reads workload that sustains parked dispatchers past pool size" as an open candidate since 2026-04-30. The implementation it unlocks: re-testing the reader-pool cap exp 105 rejected — legitimately re-runnable because exps 118/120/122 restructured dispatch since (the journal's "rejection's reason must have changed" bar).

Approach

  • Measurement: benchmark/profile/sustained_concurrent_reads_audit.dart — 8/16/32 concurrent read clients (point + range selects, no streams, no writes — nothing elision or hash suppression can skip), reporting throughput plus the exp 115 dispatcher counters.
  • Implementation under test: -DRESQLITE_READER_CAP=n compile-time override in Database.open (const-folded; default builds unchanged; not public API), A/Bing caps 4/6/8/12 on the new lane and 4 vs 8 on the exp-147 guardrails.

Results — both halves, per the rule

Measurement (counter gate satisfied): at cap 4, virtually every request parks — 12,795/12,800 at 32 clients, max depth = clients − 4, zero wake retries (exp 118's FIFO holds under sustained overload). The lane the candidate asked for exists and sees what it was meant to see.

Implementation (rejected, with current evidence):

lane cap 4 cap 8 cap 12
reads, 8 clients (ops/ms) 36.5 43.5 50.4
reads, 32 clients (ops/ms) 75.8 83.4 86.8
A11c overlap (guardrail) 127.8 ms 174.1 ms (+36%)
keyed-PK (guardrail) 24.7 ms 31.8 ms (+29%)

Reads gain +10–38%, but exp 105's completion-churn mechanism survives the 118/120/122 dispatch restructuring — the canonical stream workloads pay far more than the reads lane earns.

Outcome

Measurement accepted; cap raise rejected — rejection upgraded from stale to current. The 2026-04-30 candidate is consumed and pruned. Future pool-scheduling ideas must win on both the reads-saturation lane and the fan-out guardrails; an elastic pool consuming the parked counters is the only shape with a mechanism for that (recorded in signals.json). Single-pass caveat noted in the writeup (one cap-6 outlier omitted); the guardrail deltas are 3–4× today's observed noise bands and confirm a known mechanism.

Test plan

  • 274/274 tests; dart analyze lib test benchmark clean; finalizer green
  • Release-suite record committed (benchmark/results/2026-06-11T10-19-38-exp162-…)
  • Reads lane + guardrail A/Bs in the writeup

🤖 Generated with Claude Code

… run)

First run under the paired-measurement rule: ships the reads-saturation
lane the signal map requested since 2026-04-30 AND executes the
implementation it unlocks in the same pass.

Measurement: benchmark/profile/sustained_concurrent_reads_audit.dart —
8/16/32 concurrent read clients, no streams, no writes; at the default
cap of 4, 12,795/12,800 requests park (max depth = clients - cap) with
zero wake retries, satisfying the exp 115 counter gate.

Implementation under test: -DRESQLITE_READER_CAP compile-time override
(const-folded, tree-shaken at default, not public API) A/Bing caps
4/6/8/12. Reads gain +10-38%, but the exp-147 guardrails reject the
raise on the CURRENT dispatch structure: A11c overlap +36%, keyed-PK
+29% at cap 8 — exp 105's completion-churn mechanism survives exps
118/120/122, upgrading that rejection from stale to current. Candidate
consumed and pruned from signals.json; the lane and counters remain for
any future pool-scheduling idea (which must now win on both shapes).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant