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

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