[rabbitmq-discuss] Exchange with throttling

[Tim Watson]

On 30 Jul 2012, at 10:45, Félix López <jaaaelpumuki at gmail.com> wrote:

> Definitely I would like to extend the flow control mechanism to support something similar as I've done with plugin, so someone can set a maximum messages per second or something similar
> 

The flow control mechanism at the moment uses the concept of credit. You could possibly use internal or user defined sensors to limit or release available credit, without introducing throttle points at unnatural junctions in the process flow. I'm not saying we would do that, just that it sounds like a more convincing approach to customising flow control. The key thing is to understand where you actually want to introduce back pressure, as apply it in the wrong place almost certainly won't help and a lot of careful thought went into designing the existing approach, so (a) changing that would require just as much careful consideration and (b) opening the choice of how to apply throttling to user defined actions, sensors or throttles would require even more careful design. We would also have to consider the implications of supporting this, as any arbitrary user code that runs inside rabbit can have a variety of effects which need to be understood and documented.

I would also like to offer another architectural approach to meeting this requirement. By introducing traffic management in a border controller you obviate the need to alter the broker's behaviour in potentially unpredictable ways. A border control component doesn't have to be AMQP aware, so you can defer to smart network kit or a trusted software implementation. If a single connection (to a given endpoint) can be both producer and consumer, then a traffic manager that isn't aware of AMQP framing could potentially block progress by, for example, preventing ACKs from being delivered where a single client connection is handling both roles over two different channels. In this case, you could deploy a rabbit node to act as a border controller and use an intermediary client (say the erlang direct client, which is likely to be very efficient in this respect) to do the rate limiting before forwarding messages to the real destination endpoint. I think it's worthwhile exploring the alternative possibilities before adding complexity to the broker.

> 2012/7/30 Tim Watson <tim at rabbitmq.com>
> Just to add to Emile's comments, I there are a couple of things to consider here.
> 
> Firstly, it's important to point out that letting the Channel process mailbox fill up could lead to unexpected and unpredictable performance characteristics, and doesn't appear to offer anything that per-connection flow control isn't already doing. Also, creating an mnesia transaction for each routing operation is likely to produce an altogether *different* kind of throttling of Rabbit's performance across a cluster, and probably (in fact, almost certainly) not the one you intended.
> 
> I would strongly recommend reconsidering this approach. If you're interested in extending the flow control mechanism to support alternative measures, then perhaps we should have a collective conversation about that instead, as Emile is quite right in suggesting that approach makes more sense.
> 
> Cheers,
> Tim
> 
> 
> On 07/28/2012 11:52 AM, Félix López wrote:
>> Thanks, 
>> 
>> I've finally made a plugin to do that. I think what I wanted to do It cannot be possible with mechanism you sent me in the email. 
>> 
>> The plugin is here https://github.com/flopezluis/rabbitmq-throttling-exchange, It has a lot to improve and certainly I'm not sure of the impact of this exchange in the performance of rabbitmq.
>> 
>> 
>> 2012/7/24 Emile Joubert <emile at rabbitmq.com>
>> Hi,
>> 
>> On 23/07/12 18:20, Félix wrote:
>> > Is there anything similar in rabbitmq?
>> 
>> Yes, the broker has a connection-based flow control mechanism - see
>> http://www.rabbitmq.com/memory.html#per-connection
>> and a blog post that explains further:
>> http://www.rabbitmq.com/blog/2012/04/17/rabbitmq-performance-measurements-part-1/
>> 
>> Bear in mind that blocking an Erlang process will lead to a backlog in
>> its internal mailbox without slowing down the network. Also, the
>> exchange is not a natural control point for bandwidth limiting, because
>> an exchange is not a process. A channel would be a more natural choice.
>> You may be able to adapt the existing flow control mechanism to grant
>> credits based on bandwidth rather than message count.
>> 
>> 
>> 
>> -Emile
>> 
>> 
>> 
>> 
>> -- 
>> http://www.linkedin.com/in/flopezluis
>> 
>> It's easier to ask forgiveness than it is to get permission
>> 
>> 
>> ".....it doesn't matter how many times you fail. It doesn't matter how many times you almost get it right. No one is going to know or care about your failures, and either should you. All you have to do is learn from them and those around you because...All that matters in business is that you get it right once. Then everyone can tell you how lucky you are."
>> --Mark Cuban"
>> 
>> "Always be the worst guy in every band you're in." If you're the best guy there, you need to be in a different band. And I think that works for almost everything that's out there as well." Pat Metheny
>> 
>> 
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> 
> 
> 
> 
> -- 
> http://www.linkedin.com/in/flopezluis
> 
> It's easier to ask forgiveness than it is to get permission
> 
> 
> ".....it doesn't matter how many times you fail. It doesn't matter how many times you almost get it right. No one is going to know or care about your failures, and either should you. All you have to do is learn from them and those around you because...All that matters in business is that you get it right once. Then everyone can tell you how lucky you are."
> --Mark Cuban"
> 
> "Always be the worst guy in every band you're in." If you're the best guy there, you need to be in a different band. And I think that works for almost everything that's out there as well." Pat Metheny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120731/420dd120/attachment.htm>