Make avg_wait_time a meaningful metric #727
Open
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
added 3 commits
June 15, 2022 20:06
Currently avg_wait_time is calculated as the wait time accumulated by clients that were assigned a backend in the current stats_period and averaged over the time in that period. That means that a connection that's been waiting for 10 minutes will cause (assuming the default stats_period of 60s) a reported 10s average wait time in the stats_period it is assigned a connection (10m = 600s then 600s / 60s). It's fairly obvious that's not meaningful, because the reported value has no relation to the wait time experienced by an average client. If we instead keep track of how many times backends have been assigned for the current pool (if we were limited to transaction pooling, we could use transaction count, for example, but we want something that's generic across all pooling modes) then we can report the wait time experienced on average by a client assigned a backend during the current stats period.
This was referenced Oct 13, 2023
JelteF
reviewed
Oct 13, 2023
include/bouncer.h
Outdated
| @@ -235,6 +235,7 @@ int pga_cmp_addr(const PgAddr *a, const PgAddr *b); | |||
| * Stats, kept per-pool. | |||
| */ | |||
| struct PgStats { | |||
| uint64_t backend_assignment_count; | |||
There was a problem hiding this comment.
Do we really need this new counter? Isn't xact_count effectively the same as backend_assignment_count?
There was a problem hiding this comment.
I guess it's close but not always the same. Transaction count only gets incremented at the end of the transaction and this gets incremented at the start. So yeah this new counter is needed. I do think we should expose this new counter to users too though, otherwise it's impossible to calculate the total wait time for users.
JelteF
requested changes
Oct 13, 2023
|
I made the changes I wanted from this PR and pushed them to your branch. Barring objections, I'll probably merge this next week. |
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.
Currently avg_wait_time is calculated as the wait time accumulated by
clients that were assigned a backend in the current stats_period and
averaged over the time in that period. That means that a connection
that's been waiting for 10 minutes will cause (assuming the default
stats_period of 60s) a reported 10s average wait time in the
stats_period it is assigned a connection (10m = 600s then 600s / 60s).
It's fairly obvious that's not meaningful, because the reported value
has no relation to the wait time experienced by an average client.
If we instead keep track of how many times backends have been assigned
for the current pool (if we were limited to transaction pooling, we
could use transaction count, for example, but we want something that's
generic across all pooling modes) then we can report the wait time
experienced on average by a client assigned a backend during the current
stats period.
As cleanup first (to make sure I understand the stats calculation) I uncovered
and removed dead code (in separate commits).
Fixes #316