poorbarcode commented on code in PR #386:
URL: https://github.com/apache/pulsar-site/pull/386#discussion_r1117452409
##########
docs/concepts-throttling.md:
##########
@@ -0,0 +1,167 @@
+---
+id: concepts-throttling
+title: Message dispatch throttling
+sidebar_label: "Message throttling"
+---
+
+## Overview
+
+### What is message dispatch throttling?
+
+Large message payloads can cause memory usage spikes that lead to performance
decreases. Pulsar adopts a rate-limit throttling mechanism for message
dispatch, avoiding a traffic surge and improving message deliverability. You
can set a threshold to limit the number of messages and the byte size of
entries that can be delivered to clients, blocking subsequent deliveries when
the traffic per unit of time exceeds the threshold.
+
+For example, when you configure the dispatch rate limit to 10 messages per
second, then the number of messages that can be delivered to the client per
second is up to 10.
+
+
+
+### Why use it?
+
+Message dispatch throttling brings the following benefits in detail:
+
+- **Limit broker’s read request loads to BookKeeper**
+
+ Messages are persistently stored in the BookKeeper cluster. If a large
number of read requests cannot be fulfilled using the cached data, the
BookKeeper cluster may become too busy to respond, and the broker's I/O or CPU
resources can be fully occupied. Using the message dispatch throttling feature
can regulate the data flow by limiting the broker’s I/O and CPU load, as well
as BookKeeper’s read request load.
+
+- **Balance the allocation of broker’s hardware resources at
topic/subscription levels**
+
+ A broker instance serves multiple topics at one time. If a topic is
frequently looked up, it will occupy almost all of the I/O, CPU, and memory
resources, causing other topics cannot be looked up. Using the message dispatch
throttling feature can limit the allocation of broker’s hardware resources
across topics.
+
+- **Limit the allocation of client’s hardware resources at topic/subscription
levels**
+
+ When there is a large backlog of messages to consume, clients may receive a
large amount of data in a short period of time, which monopolizes their
computing resources. Since the client has no mechanisms to proactively limit
the consumption rate, using the message dispatch throttling feature can also
regulate the allocation of the client’s hardware resources.
Review Comment:
Hi @tisonkun
>> Since the client has no mechanisms to proactively limit the consumption
rate
> Why? Consumer#receive receives one message per call. Client app can define
their consume logic.
The code that users consume messages often looks like this:
```java
while ((msg = consumer.receive()) != null){
doService(msg)
}
```
Method `doService` costs more cpu, memory, and other resources than
receiving messages. If there is a lot backlog in this topic( perhaps more than
one topic ), then these threads of consumers will keep working busy, which puts
other services( such as web service ) on the same machine at a disadvantage.
In a standard service, messages tend to be processed asynchronously (not
high priority), so there are scenarios where customers need to limit the amount
of system resources consumed by consuming messages to keep other services
working
--
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]
