[rabbitmq-discuss] Keeping track of exchanges -- Any Advice

Simon MacMullen simon at rabbitmq.com
Mon Jan 30 11:42:18 GMT 2012

On 30/01/12 06:31, MarcusR wrote:
> Hello Simon, thanks for the response.
> I am not really sure to be honest. I am not very familiar with message
> brokers and their performance characteristics. I suppose I could have
> a topic exchange and then bind queues to various topics... Such as
> have a queue for user1.queu1, user2.queue1, user3.queue1, etc

Unless you need wildcards you may not even need a topic exchange. *If* 
routing turns out to be an expensive thing for you then a direct 
exchange can give a notable performance boost.

> My question is how expensive is routing?

Depends :) If you're sending lots of small non-persistent messages fast 
then it can become a somewhat significant factor, just because RabbitMQ 
isn't doing mush *else* per message.

Usually making routing simpler will make it faster.

> Also, regarding the routing,
> is it more performant to have one master topic exchange for all the
> users or to distribute users across multiple topic exchanges or does
> it not matter?

It doesn't matter.

> I assume rabbitmq first looks up the exchange and then goes through
> each queue to see if there is a match for routing. If this is the
> case, I imagine it would be more performant to create a thousand such
> topic exchanges and divide all the users across them as opposed to one
> topic exchange for all users.

No, it's not quite like that - topic routing is O(log(n)). But I think 
the n there is the total number of topic bindings, not per exchange.

> In the end, I plan to run several rabbitmq nodes with a bucket of
> users assigned to each rabbit node. Assigning each user to a node
> based on a hash. Is this best practice for scaling rabbitmq for this
> type of scenerio? Currently rabbitmq is the bottle neck in my
> application benchmarks so this was my plan to scale it. Please correct
> me if there is a better practice.

This sort of sharding is probably the most scalable solution if it's 
practical. If it's not practical then clustering or federation would be 
alternative routes...

Cheers, Simon

Simon MacMullen
RabbitMQ, VMware

More information about the rabbitmq-discuss mailing list