[rabbitmq-discuss] Scaling Throughput with Highly Available Queues

Richard Raseley richard at raseley.com
Tue Mar 19 20:56:43 GMT 2013


Thank you for your quick response. With regard to your suggestion on using
a specific replica count via the "exactly" ha-mode - wouldn't there still
be a bottleneck in the master node of the cluster? My understanding is that
it has a hand in all operations (obviously true in a cluster with ha
queues), but that it is in-line with all non-publishing operation. Is this
a correct understanding?



On Tue, Mar 19, 2013 at 1:49 PM, Matthias Radestock
<matthias at rabbitmq.com>wrote:

> Richard,
> On 19/03/13 20:40, Richard Raseley wrote:
>> Is it correct to say that adding nodes to a cluster in which you are
>> exclusively using highly available queues will not increase performance
>> (and in fact me degrade it) but will instead simply increase resiliency?
>> My thought is that the overhead for each message publish would increase
>> linearly as you added nodes for a cluster, as each of those messages
>> have to be replicated to each node (e.g. there is going to be more
>> latency in acknowledging the publishing of a 1KB message to a 2 node
>> cluster vs. a 10 node cluster.
> That's about right. For the 'all' ha-mode. However, ...
>  Furthermore, if there is a desire to add throughput capacity while still
>> utilizing highly available queues, would it be best to add additional
>> clusters with mirrored configurations (e.g. 2x 2-node clusters) and put
>> them behind the same load balancer?
> You could switch to the 'exactly' ha-mode - see
> http://www.rabbitmq.com/ha.**html#genesis<http://www.rabbitmq.com/ha.html#genesis>- where queues are mirrored on a given number of nodes, regardless of how
> many nodes there are in the cluster in total.
> Regards,
> Matthias.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130319/500717d2/attachment.htm>

More information about the rabbitmq-discuss mailing list