bedrock-kv / bedrock
78%
develop: 82%

LAST BUILD BRANCH: bedrock-5yi/election-flapping
DEFAULT BRANCH: develop
Repo Added
Token s5ZhiY9p3BKcBOY6Au8fohhCDmrp89s9W regen
Build 582 Last
Files 216
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

LAST BUILD ON BRANCH integration/commit-path-perf
branch: integration/commit-path-perf
CHANGE BRANCH
x
Sync Branches

coverage: 78.229% (-0.02%) from 78.252%
85d1f8940e6e86c1c235769f8156be459b605880-PR-210

Pull #210

github

jallum 
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 #210: Integration/commit path perf

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

Relevant lines Covered
8672 RELEVANT LINES 6784 COVERED LINES
1029.33 HITS PER LINE
Source Files on integration/commit-path-perf

Recent builds

Builds Branch Commit Type Ran Committer Via Coverage
85d1f894... integration/commit-path-perf 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... Pull #210 jallum github
78.23
See All Builds (582)

Badge your Repo: bedrock

We detected this repo isn’t badged! Grab the embed code to the right, add it to your repo to show off your code coverage, and when the badge is live hit the refresh button to remove this message.
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

Refresh