-
Notifications
You must be signed in to change notification settings - Fork 4.1k
perf: quantify network space overhead #18919
Copy link
Copy link
Closed
Labels
A-kv-clientRelating to the KV client and the KV interface.Relating to the KV client and the KV interface.A-kv-replicationRelating to Raft, consensus, and coordination.Relating to Raft, consensus, and coordination.C-performancePerf of queries or internals. Solution not expected to change functional behavior.Perf of queries or internals. Solution not expected to change functional behavior.T-kvKV TeamKV TeamX-staleno-issue-activity
Metadata
Metadata
Assignees
Labels
A-kv-clientRelating to the KV client and the KV interface.Relating to the KV client and the KV interface.A-kv-replicationRelating to Raft, consensus, and coordination.Relating to Raft, consensus, and coordination.C-performancePerf of queries or internals. Solution not expected to change functional behavior.Perf of queries or internals. Solution not expected to change functional behavior.T-kvKV TeamKV TeamX-staleno-issue-activity
Similar to #18659 I decided to look at the overhead in
Batch{Request,Response}for simple "kv" reads (i.e. a singleScan{Request,Response}in the batch).The
Scan{Request,Response}consume exactly 20% of the total bytes sent/received. The request and response txn consume 64% of the bytes. The response txn is nearly identical to the request txn with onlyTransaction.MaxTimestamphaving changed.There are some small gains to be had by converting
Batch{Request,Response},TransactionandTxnMetato proto3 to avoid encoding zero value primitive fields. There is a large gain to be had by only returning the delta of the transaction in the response.Cc @andreimatei who suggested last week that we develop a more principled way to update the transaction upon receiving a response.