kvserver: add raft.replication.latency #106094
Merged
Conversation
This file contains 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
|
It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR? 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
|
This change is |
erikgrinaker
approved these changes
Jul 5, 2023
Distinguish the unreplicated from the replicated case, since we want metrics for the replicated one and to that end will need to construct a different endCmds in a follow-up commit.
We're not actually measuring replication latency yet, but this will happen in the next commit.
The help text says it all: ---- The duration elapsed between having evaluated a BatchRequest and it being reflected in the proposer's state machine (i.e. having applied fully). This encompasses time spent in the quota pool, in replication (including reproposals), and application, but notably *not* sequencing latency (i.e. contention and latch acquisition). No measurement is recorded for read-only commands as well as read-write commands which end up not writing (such as a DeleteRange on an empty span). Commands that result in 'above-replication' errors (i.e. txn retries, etc) are similarly excluded. Errors that arise while waiting for the in-flight replication result or result from application of the command are included. Note also that usually, clients are signalled at beginning of application, but the recorded measurement captures the entirety of log application. Commands that use async consensus will still cause a measurement that reflects the actual replication latency, despite returning early to the client. ---- Fixes cockroachdb#83262. Epic: CRDB-25287 Release note (ops change): a histogram metric raft.replication.latency was added. It tracks the time between evaluation and application of the command. This includes time spent in the quota pool, in replication (including reproposals) as well as log application, but notably *not* sequencing latency, i.e. contention and latch acquisition.
|
bors r=erikgrinaker |
|
Build succeeded: |
This was referenced Jul 6, 2023
craig bot
pushed a commit
that referenced
this pull request
Jul 11, 2023
106095: kvserver: misc replication-related cleanups r=erikgrinaker a=tbg These are a few cleanups done as part of #106094 which aren't in that PR's main workstream. Epic: CRDB-25287 Release note: None Co-authored-by: Tobias Grieger <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The help text says it all:
The duration elapsed between having evaluated a BatchRequest and it being
reflected in the proposer's state machine (i.e. having applied fully).
This encompasses time spent in the quota pool, in replication (including
reproposals), and application, but notably not sequencing latency (i.e.
contention and latch acquisition).
No measurement is recorded for read-only commands as well as read-write commands
which end up not writing (such as a DeleteRange on an empty span). Commands that
result in 'above-replication' errors (i.e. txn retries, etc) are similarly
excluded. Errors that arise while waiting for the in-flight replication result
or result from application of the command are included.
Note also that usually, clients are signalled at beginning of application, but
the recorded measurement captures the entirety of log application.
Commands that use async consensus will still cause a measurement that reflects
the actual replication latency, despite returning early to the client.
Fixes #83262.
Epic: CRDB-25287
Release note (ops change): a histogram metric raft.replication.latency was added.
It tracks the time between evaluation and application of the command. This includes
time spent in the quota pool, in replication (including reproposals) as well as log
application, but notably not sequencing latency, i.e. contention and latch
acquisition.