lhotari commented on PR #25061: URL: https://github.com/apache/pulsar/pull/25061#issuecomment-3645275958
> The previous implementation already followed your approach: https://github.com/apache/pulsar/blob/v4.1.2/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentDispatcherSingleActiveConsumer.java#L228-L231 This is not what I mean. The permits should be consumed from rate limiters before retrieving the entries. After sending, the difference should be adjusted to the actual. > > This PR changes that behavior by consuming tokens before sending entries, so that multiple dispatchers cannot use the same quota concurrently. This is not optimal due to extra work added to the system. > > > This would address the concerns that I have about performance impacts when entries are read and then dropped before sending out to consumers. > > Some performance impact is expected once a dispatch rate limit is configured. Similar to the producer rate limiter, the broker may need to pause processing message. From the broker's perspective, various settings such as read batch sizes can mask the overshoot, so Prometheus may still show values that appear aligned with the configured rate. However, this alignment is influenced by several layers of constraints, not strictly by the limiter. My goal is to ensure the code path itself behaves rigorously so that the limiter remains accurate even under concurrency. With the performance impact, I mean that this solution would require the system to do more work since it performs unnecessary work in the case of exceeding the rate limit. That's something that is not optimal at all. It's possible to eliminate the extra work by acquiring the tokens before retrieving of the entries is made and adjusting the difference later. Adding extra work to an already highly loaded system often leads to cascading failures. That's why it should be avoided at all cost. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
