[rabbitmq-discuss] TCP Backpressure / Flow Control in C# producer
Matthias Radestock
matthias at rabbitmq.com
Wed Aug 8 10:49:42 BST 2012
Ulli,
On 08/08/12 10:29, Ulli Berthold - Exactag GmbH wrote:
> we're running rabbit 2.8.4 / 2.8.5 on 64bit linux servers with 64bit
> erlang and plenty of memory, and there was no "high watermark"
> warning in the logs either. Just to make sure i'm not erring to much
> - if the rabbit web ui shows a connection as "flow" instead of
> "running" or "blocked" that does mean it is in flow control
> (backpressure), correct?
Correct, but as noted at
http://www.rabbitmq.com/memory.html#per-connection, this kind of flow
control is triggered many times a second.
It's really not something an application should need to worry about. And
it does *not* mean the producer is blocked, since there are many buffers
between the application and the broker connection handler that need to
fill up first. That way spikes can be absorbed.
Obviously if producers attempt to publish at a *sustained* rate that is
higher than the broker can handle then backpressure will propagate to
the client and slow them down. The point at which that happens should be
way higher than the 3kHz rate you anticipate.
Matthias.
More information about the rabbitmq-discuss
mailing list