Add transaction log read-path benchmark (baseline capture)#546
Draft
harper-joseph wants to merge 2 commits into
Draft
Add transaction log read-path benchmark (baseline capture)#546harper-joseph wants to merge 2 commits into
harper-joseph wants to merge 2 commits into
Conversation
Adds a 4-pattern read-path benchmark that surfaces the contention
characteristics of the transaction log under concurrent subscribers:
1. Bulk forward scan, no writes
2. Bulk forward scan with 1 concurrent writer
3. High-frequency short-range queries (1k iterators × 8 workers)
4. Cursor-advance tail scan with 1 concurrent writer
Each pattern compares rocksdb-js against lmdb with matched lazy-durability
semantics (`noSync: true`) and Harper-realistic LMDB options
(`getRange({snapshot: false})`, numeric timestamp-like keys).
Runs as part of the standard `pnpm bench` flow. Total wall time ~20s
(4 benches × ~5s sample window) — fits comfortably in CI.
This PR is intentionally a draft so we can capture the baseline numbers
from the self-hosted CI runner before any optimization changes land.
A separate PR will introduce the read-path optimizations and we'll
compare CI numbers.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
📊 Benchmark Resultsget-sync.bench.tsgetSync() > random keys - small key size (100 records)
getSync() > sequential keys - small key size (100 records)
ranges.bench.tsgetRange() > small range (100 records, 50 range)
realistic-load.bench.tsRealistic write load with workers > write variable records with transaction log
transaction-log.bench.tsTransaction log > read 100 iterators while write log with 100 byte records
Transaction log > read one entry from random position from log with 1000 100 byte records
worker-put-sync.bench.tsputSync() > random keys - small key size (100 records, 10 workers)
worker-transaction-log-read.bench.tsTransaction log read access patterns (8 workers) > Bulk forward scan, no writes: 8 workers each scan ~8000 entries
Transaction log read access patterns (8 workers) > Bulk forward scan with 1 concurrent writer (7 readers)
Transaction log read access patterns (8 workers) > Short-range queries: 8 workers each open 1000 iterators per tick
Transaction log read access patterns (8 workers) > Cursor-advance tail scan with 1 concurrent writer (7 readers, 50 writes/tick)
worker-transaction-log.bench.tsTransaction log with workers > write log with 100 byte records
Results from commit 0bb68f8 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Draft PR — this exists solely to capture baseline numbers from the
self-hosted CI runner before a separate PR introduces read-path
optimizations. Once the baseline is on record, we can compare against
the optimized PR's CI run.
Adds
benchmark/worker-transaction-log-read.bench.ts— a 4-patternread-path benchmark designed to expose mutex/atomic contention on the
transaction log read path under concurrent subscribers.
Benchmarks added
All four run at 8 workers:
LMDB options aligned with Harper's actual audit-store usage:
Why this is just the bench
A companion PR (read-path optimizations) makes substantial C++ changes to the transaction log read path. Before those changes are evaluated by CI, we need to know what the runner produces on baseline so we can quantify the impact. Splitting it this way means:
Test plan
Bench expectations on baseline
From local runs on baseline (no opts, 8-core M-series Mac):
The short-range row is the interesting one — that's the workload where the planned read-path optimizations provide a 22× speedup, flipping rocksdb-js from a 4× regression to a 5× lead vs LMDB.
🤖 Generated with Claude Code