[rabbitmq-discuss] Keeping track of exchanges -- Any Advice
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
More information about the rabbitmq-discuss