Repository navigation
Read-endpoint SLAs under ingestion load #870
Description
TL;DR
Read endpoints must hold their latency SLAs while the node is ingesting at target load — not just against a quiet store. Today the ingest benchmarks (#771) and query benchmarks (#856) run separately; this issue combines them into one scenario.
Scope
- A combined scenario: paced hot ingestion running at a phase's block cadence (
--close-interval= 2 s / 1 s / 600 ms for phases 1/2/3 as defined in Synthetic ledger datasets for Phases 1–3 ("golden packs") #867) with the query benchmarks firing concurrently against the same node. - Input datasets per phase (Synthetic ledger datasets for Phases 1–3 ("golden packs") #867), so both the write pressure and the data shape match the phase being claimed.
- Sweep query concurrency; measure read p50/p99 per endpoint (getTransaction, getEvents, getLedgers, getTransactions equivalents in the full-history store).
- Report interference explicitly, in both directions: reads-under-load vs the quiet-store baseline from Full-history query benchmark commands — reads across all data types #856, and ingestion pace-lag with and without read load.
Done when
For each phase in scope, a pass/fail statement per read endpoint under ingestion load, reproducible as a campaign (ideally runnable through #868).
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
tamirms commentedon Oct 26, 2026
Proposal to widen this benchmark's scope for Phase 3: run paced ingestion, getTransaction load and the chunk-boundary jobs together on one node.
Every 10,000 ledgers, two jobs start beside hot ingestion:
The draft ingest stack (#1139 to #1146) adds bench modes (#1143) that measure ingest p99 beside one of these jobs at a time, without reads. Two cases are still not measured:
Suggested scope: