[rabbitmq-discuss] High-performance routing strategies

[Helena Edelson]

Thanks Matthew, this is great information. I have just a few more questions
in-line below:


On 3/21/11 9:43 AM, "Matthew Sackman" <matthew at rabbitmq.com> wrote:

> Helena,
> 
> On Mon, Mar 21, 2011 at 08:35:47AM -0600, Helena Edelson wrote:
>> I am curious to know what routing strategies and broker topologies are being
>> implemented for performance in similar scenarios of:
>> 
>> * One broker must handle the load of 1000 distributed agents/clients
>> * A cluster of brokers handles 10,000 or more distributed agents/clients
> 
> Neither of these scenarios will necessarily induce high load in
> RabbitMQ.
> 
> 100,000 queues on a single broker is fine - I've just created that on my
> desktop with no problems. You could likely get to well over a million
> with a bit of tuning and enough RAM.

Can you direct me toward acknowledged, tested RAM requirements? I've seen
some information pass by in the list and other docs but would like to see
something concrete.

> 
> Exchanges and bindings are even cheaper in terms of the memory cost.
> 

Rephrasing:
Say I have an application consisting of a server to 20,000 agents. Each
agent-server request/response conversation can be broken down into 15 basic
classification types with say 5 sub-conversation types. If I leverage topic
exchanges for their behavioral flexibility, primarily use hierarchical
routing keys and say, create a topic per major classification/conversation
and use more specific routing keys for sub-converstations creating more
lower-cost Bindinds, are you saying that is not more performant than going
with an exponential amount of direct exchanges and more queues? I can
partition and load balance the queues that would handle the very large
message payloads easily enough, but for general high-traffic small JSON
payloads/quick turn around for instance, what is the recommendation?
 
> Doing 10,000+ connections to a single node is also fine. There is
> something somewhere which affects connection creation in RabbitMQ which
> causes a log_2(N) slow down on connection establishment: i.e. whilst
> initially, I can do about 1000 new connections a second, beyond 10,000
> or so connections, the rate of connection establishment slows a little.
>

With regard to connections and channels, I wonder if someone can point me to
data or research on thread behavior, leveraging threads going to
sleep/waking up vs creating/closing connections for each client request to
the broker.

 
> What does induce load is binding/exchange churn rate and message rate
> and message size.
> 
> A sustained load of N thousand binding creation/deletion events per
> second will likely overwhelm a single machine, and due to the fact that
> such changes have to be distributed to all nodes in a cluster will
> likely also induce substantial load on a large cluster too. Isolating
> such things really requires stuff like federation which AMQP isn't
> really well suited to, in the general case.

If I am delegating to a Queue to handle runtime requests to create queues,
exchanges, and bindings, might that take care of resultant capacity issues?
I have typically federated JMS brokers and wonder about a similar
topology/configuration.
 
> Matthew
>