why is deliver/get number much more than ack and incoming?

[li he]

I have a queue with 24 consumers, each consumer process messages synchronously - one is consumed after previous one acked. 

Normally, the consumers is enough to process the messages, and the incoming, deliver/get, ack rate is almost same, such as this:

But after the moment of incoming outbreak-increasing,  the deliver/get will be much more than incoming and ack, like this:

As we seen, the Unacked is 24, equals to the number of consumers,  and the are 109 messages wait in the queue.

But I am confusing why deliver/get is 149/s, and incoming and ack is 50/s ?

The environments is:

exchange type:           topic

consumer number:     24

prefech count:            2

auto-ack:                    false

client:                         pika

Anyone can help me? Thank you!

 

[Michael Klishin]

Deliveries and acknowledgements are not coordinated unless there's a prefetch (outstanding delivery limit) [1].

There is no limit by default.

At a given moment in time RabbitMQ can be delivering more messages to a consumer, and some consumers may use

automatic acknowledgements [2] which means they will never ack anything and thus are "invisible" if you look at the ack

rate alone. Lastly, it's possible to acknowledge N deliveries at once [3].

1. https://www.rabbitmq.com/confirms.html#channel-qos-prefetch

2. https://www.rabbitmq.com/confirms.html#acknowledgement-modes

3. https://www.rabbitmq.com/confirms.html#consumer-acks-multiple-parameter

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/0317f700-0ef7-4ca1-a5c8-7d753027c30e%40googlegroups.com.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

[li he]

Thank you for your answer. 

I know rabbitmq supports ack multiple deliveries at once, but in my scene message was processed synchronously in a consumer, that meas each consumer have a synchronous loop: consume -> process -> ack,  message can only be consume after the previous one acked.

So, ack n deliveries at once may not appeared.

The values are defining as: 

* "deliver" refers to messages delivered as a result of basic.consume. 

* "get" refers to messages that arrived in response to basic.get.
* "deliver/get" is the sum of both.
* "ack" just shows the ack rate, if messages are delivered with autoack then this rate can be lower or zero.

I need to add one point: each message process time is approximately 0.15-0.4s in my project.

Considering the prefetch count is 2,  and there are total 133 message in queue and incoming almost equals to ack rate,  is it  possible 24 consumers  receiving 24*2=48 message onces time (each consumer receives prefech=2 messages  once)?

Only this can explain why the diliver/get rate is much higher. If that is the case, meaning each consumer has one message cached in memory while one message is processing.

So the nature of this problem is what is rabbitmq doing when prefech=2 or > 1, is the consumer caches prefech-count messages in client ?

在 2020年4月3日星期五 UTC+8上午11:56:44，Michael Klishin写道：

Deliveries and acknowledgements are not coordinated unless there's a prefetch (outstanding delivery limit) [1].

There is no limit by default.

At a given moment in time RabbitMQ can be delivering more messages to a consumer, and some consumers may use

automatic acknowledgements [2] which means they will never ack anything and thus are "invisible" if you look at the ack

rate alone. Lastly, it's possible to acknowledge N deliveries at once [3].

1. https://www.rabbitmq.com/confirms.html#channel-qos-prefetch

2. https://www.rabbitmq.com/confirms.html#acknowledgement-modes

3. https://www.rabbitmq.com/confirms.html#consumer-acks-multiple-parameter

On Fri, Apr 3, 2020 at 6:41 AM li he <bbhe...@gmail.com> wrote:

I have a queue with 24 consumers, each consumer process messages synchronously - one is consumed after previous one acked. 

Normally, the consumers is enough to process the messages, and the incoming, deliver/get, ack rate is almost same, such as this:

But after the moment of incoming outbreak-increasing,  the deliver/get will be much more than incoming and ack, like this:

As we seen, the Unacked is 24, equals to the number of consumers,  and the are 109 messages wait in the queue.

But I am confusing why deliver/get is 149/s, and incoming and ack is 50/s ?

The environments is:

exchange type:           topic

consumer number:     24

prefech count:            2

auto-ack:                    false

client:                         pika

Anyone can help me? Thank you!

 

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitm...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/0317f700-0ef7-4ca1-a5c8-7d753027c30e%40googlegroups.com.

[Michael Klishin]

If prefetch is set to two and there are 24 consumers, there will be about 48 outstanding deliveries pending confirmation

at any given time. Obviously since deliveries, acknowledgements and stats emission by queues are all asynchronous,

the number can be 47 at one moment and 49 at another.

Also note that prefetch is a per-channel setting so if you have N channels with one consumer per channel, the effective

prefetch per consuming app process will be 2*N.

You can always take a traffic capture with tcpdump and analyse it with Wireshark [1], including "zooming in" (filtering by) a single connection

to make this easier. Or use your own application's metrics and logs.

1. https://www.rabbitmq.com/amqp-wireshark.html

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/27345b44-cbd7-46ed-b265-2633179bac19%40googlegroups.com.

[li he]

Thank you!

在 2020年4月3日星期五 UTC+8下午3:27:12，Michael Klishin写道：

To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/27345b44-cbd7-46ed-b265-2633179bac19%40googlegroups.com.