[rabbitmq-discuss] Connection is always in "flow" State.
simon at rabbitmq.com
Thu Jul 10 16:41:24 BST 2014
On 10/07/2014 4:23PM, Jason McIntosh wrote:
> Interesting on the 3.3 change. SO I gotta ask about this situation on
> that (though it sounds off hand that'll fix the behavior I've seen on
> 3.2.4). If a consumer is consumer at 80 msgs/second, but incoming rates
> are able to publish at 5k a second and the server CPU's/disks/etc.
> aren't being touched, will rabbit then put back pressure on the
> publishing rate forcing it down to 72 msgs/second (~10% less than
No, no, no!
(And this is why writing documentation is hard! At least for me.)
I somewhat oversimplified. What really happens is that the queue will
choose to do work that relates to consumers rather than publishers as
1) The queue is running flat out; it never has any idle time.
2) The queue actually has work to do that pertains to consuming.
3) Messages are being consumed at less than 110% of the rate they're
In the case you describe above, 2) will be false 99% of the time, at
which point the queue will accept publishes as fast as it can.
In other words, when I said "if consumers and producers are both going
as fast as they can" I meant if the limiting factor is the queue itself,
not whatever work they're doing.
I hope that is clearer this time round.
> I'd assume then that'd propagate up to the publisher if
> there's a chain of rabbit servers all running 3.3 - e.g. the code
> publish to rabbit which shovels to the remote rabbit where the code
> consumer runs. In this case the code publisher would get back pressure
> that'd reduce it's publish rate to ~72msgs/second?
Which would be a disaster. It's meant to be a queuing system, after all :-)
More information about the rabbitmq-discuss