[rabbitmq-discuss] PubSub - all bindings have to be in memory?

Ben Browitt ben.browitt at gmail.com
Mon Feb 1 14:01:06 GMT 2010


Let's say RAM can fit all my bindings and that I'm using fixed sized values
with direct exchanges.
Assuming that the incoming and outgoing number of messages is constant,
should I expect the performance to degrade as the number of  bindings
increases or will it stay the same?
In other words, does a large number of queues, exchanges and bindings affect
the load even when
most of them aren't being used?


On Mon, Feb 1, 2010 at 3:43 PM, Matthew Sackman <matthew at lshift.net> wrote:

> Hi Ben,
> On Mon, Feb 01, 2010 at 07:58:52AM +0200, Ben Browitt wrote:
> > Do I have to keep all bindings in memory or is there a mode where
> rabbitmq
> > can read binding keys from disk when needed?
> I'm afraid bindings are all kept in RAM. The binding record is quite
> small (dependent on the size of the exchange name, binding key, queue
> name and any args - minimising these will help reduce memory foot print)
> so you should be able to fit quite a lot of them in RAM:
> > erts_debug:flat_size(#binding{exchange_name = <<"my_exchange">>,
> queue_name = <<"my_queue">>, key = <<"my_key">>, args = []}).
> 24
> So just 24 bytes for that record, though obviously with padding and
> longer field values, this will grow. Fixed size values here would help -
> if for example you're able to use md5sums to get the exchange name and
> queue name, and only use fanout or direct exchanges, and thus have an
> fixed sized hash for the binding key too, then that'll make estimations
> easier.
> If you can estimate given, say, twice your expected number of visitors
> and twice the expected number of articles they subscribe to how many
> bindings that would result in, then you may be able to satisfy yourself
> whether or not this is going to be a problem.
> Whilst the new persister is able to page messages out to disk, we have
> no plans just at the moment to be able to do the same for bindings.
> Please let us know how you get on.
> Matthew
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100201/6ea953ba/attachment.htm 

More information about the rabbitmq-discuss mailing list