bedrock-kv / bedrock / 85d1f8940e6e86c1c235769f8156be459b605880-PR-210

78%

develop: 82%

Build Type

Pull #210

github

Committed by jallum

Commit Message

Hold an open batch only while batches are actually filling

The proxy closed its batch on a zero timeout, which fires as soon as the
mailbox empties. With request/response clients that is immediately, so
the batch closed at one transaction and max_latency_in_ms was never
reached. Measured batch size was 1.0 at one-way concurrency and still
only 1.41 at 128-way: essentially every transaction paid a full
finalization round -- resolver plus log push, ~3.8ms.

Holding the window fixes throughput and hurts idle latency. Uncontended
writes to distinct keys, two runs averaged:

  policy        conc=1    conc=32    conc=128   p50 @128
  close now     1768/s     6749/s     7586/s    15-17ms
  hold 1ms       490/s    15598/s    24137/s     5-6ms
  adaptive      1952/s    17044/s    25962/s     4-6ms

So the wait is decided by whether recent batches FILLED. An idle proxy
sees batches of one, keeps its average low, and waits zero -- a lone
transaction is never delayed, which is the property the zero timeout got
right. Under load the average climbs within a few batches and the proxy
starts amortizing. Note the latency improves as well as the throughput:
batching removes more queueing than the deliberate wait adds.

The mechanism is two pure functions and one state field. A sweep found
larger holds strictly worse -- 8ms cost 12x at idle and LOST throughput
under load versus 1ms -- so the hold is 1ms, which is also FDB's
COMMIT_TRANSACTION_BATCH_INTERVAL_MIN.

FDB adapts the same knob from the other side: its interval tracks a
fraction of observed latency, smoothed, clamped to [1ms, 20ms]
(CommitProxyServer.actor.cpp:2843-2849, ServerKnobs.cpp:701-704). Its
floor is 1ms, so an idle FDB commit always pays it. Ours can reach zero
because version advancement is guaranteed separately by the
empty-transaction timeout.

max_latency_in_ms and max_per_batch are unchanged and still cap the
batch; this only decides whether waiting is worth it at all.

On the contended class-s... (continued)

Pull Request Pull Request #210: Integration/commit path perf

Coverage Stats

30 of 36 new or added lines in 6 files covered. (83.33%)

30 existing lines in 5 files now uncovered.

6784 of 8672 relevant lines covered (78.23%)

1029.33 hits per line