[improve][pip] PIP-406: Introduce metrics related to dispatch throttled events #23945
Conversation
This file contains hidden or 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
…led_msgs and bytes metrics
14 tasks
omarkj
pushed a commit
to omarkj/pulsar
that referenced
this pull request
Feb 7, 2025
…a schema and transaction Discussion email: Implementation PR: [improve][pip] PIP-406: Introduce pulsar_subscription_dispatch_throttled_msgs and bytes metrics apache#23945
omarkj
pushed a commit
to omarkj/pulsar
that referenced
this pull request
Feb 7, 2025
…a schema and transaction Discussion email: Implementation PR: [improve][pip] PIP-406: Introduce pulsar_subscription_dispatch_throttled_msgs and bytes metrics apache#23945
poorbarcode
reviewed
Feb 11, 2025
poorbarcode
reviewed
Feb 11, 2025
RobertIndie
reviewed
Feb 12, 2025
Member
Author
|
hi, @RobertIndie @tjiuming @poorbarcode The previous design made it difficult for users to identify where throttling was causing a high backlog. I have rewritten the PIP to separate the metrics at the broker, topic, and subscription levels. Please review it again. Thanks. |
lhotari
reviewed
Feb 22, 2025
RobertIndie
reviewed
Mar 7, 2025
Member
RobertIndie
left a comment
There was a problem hiding this comment.
I think we don't need separate metrics for both messages throttled and bytes throttled. This could make it complex for users. Could we just name it pulsar_dispatch_throttled_events and only count the number of throttled events where the message count or bytes exceed the rate limits?
So the logic would be like:
private boolean applyDispatchRateLimitsToReadLimits(DispatchRateLimiter rateLimiter,
MutablePair<Integer, Long> readLimits,
DispatchRateLimiter.Type limiterType) {
+ int originalMessagesToRead = readLimits.getLeft();
+ long originalBytesToRead = readLimits.getRight();
// update messagesToRead according to available dispatch rate limit.
int availablePermitsOnMsg = (int) rateLimiter.getAvailableDispatchRateLimitOnMsg();
if (availablePermitsOnMsg >= 0) {
@@ -414,6 +416,12 @@ private boolean applyDispatchRateLimitsToReadLimits(DispatchRateLimiter rateLimi
if (availablePermitsOnByte >= 0) {
readLimits.setRight(Math.min(readLimits.getRight(), availablePermitsOnByte));
}
+ if (readLimits.getLeft() < originalMessagesToRead || readLimits.getRight() < originalBytesToRead) {
+ rateLimiter.increaseDispatchThrottleMsgCount();
+ }
lhotari
approved these changes
Mar 13, 2025
RobertIndie
approved these changes
Mar 17, 2025
Member
Author
|
https://lists.apache.org/thread/pmgkf67ph98k5l3lr60rtg96octb397q The vote passed with 3 +1 binding.
|
walkinggo
pushed a commit
to walkinggo/pulsar
that referenced
this pull request
Oct 8, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Motivation
Documentation
docdoc-requireddoc-not-neededdoc-completeMatching PR in forked repository
PR in forked repository: