Multilog consistent read optimizations#1832
Draft
vazois wants to merge 5 commits into
Draft
Conversation
…ough passing the timeout directly through the method signature
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
Investigate and implement optimizations for the multilog consistent read path.
Optimizations
(B) Use bitshift/mask instead of division/mod for sublog idx calculation— not worth it; marginal gain with power-of-two restriction on sublog countsPre-optimization baseline
Post-optimization results
Follow-up items (optional)
Defer sketch-max update to reduce cache invalidation under concurrent load — When writers and replay threads are active alongside readers, updating the per-key sequence number sketch immediately on each replay invalidates cache lines shared with reader threads. Deferring or batching the sketch-max update avoids false sharing. Not a factor in the current BDN (no active writer), but a best-practice for production workloads.
Timestamp inversion with concurrent writers to the same sublog — Two write sessions appending to the same physical sublog can acquire AOF timestamps out of order (T1 < T2 but T2's record lands first). At replay, the sketch slot sees T2 before T1 and never updates for T1, so a reader may get a false "caught up" signal before T1's mutation is applied. Correctness gap to address.
Replay-thread pacing / coordination barrier — Without coordination, replay threads for different sublogs can diverge arbitrarily. A lightweight barrier or watermark sync would keep them roughly aligned, reducing worst-case reader wait time and bounding the staleness window without adding per-key cost on the read path.
Consolidate witness-tail into the replication stream (time-advancement sentinel) — Eliminate the separate witness-tail task by emitting a lightweight sentinel on the same connection that ships the log. The sentinel signals "time advanced to sequence N" for a sublog without appending a real AOF record. Key validations: (1) blind sequence-number acquisition is safe under monotonic-max semantics, (2) sentinel does not allocate AOF space, (3) no races with concurrent write sessions acquiring sequence numbers in parallel.