RabbitMq connection to cluster

[Zero Gravity]

Hi team,

i think i thoroughly read a lot of related documentation but i still can't say what is the best way to connect to RabbitMq cluster from performance point of view for:
1. publishing 

2. consumption 

keeping in mind that my queues have replication factor of 2, cluster consists of 3+ nodes.

Correct me if i'm wrong but here every queue has a master replica and from performance perspective i should connect to that node for publishing and consumption but it seems current neither documentation nor client libraries care about this

At the same time there's blog post (https://www.rabbitmq.com/blog/2021/07/23/connecting-to-streams#topology-of-a-stream) regarding Streams that states, let me quote:

>  It does not require a PhD to understand that the operation is not optimal if the connection and the stream leader are not on the same node. An application that publishes to a stream should connect to the node that hosts the leader of the stream, to avoid an extra network hop.

which makes me think that similar problem should be actual for classic/quorums queues as well but again i can't find anything regarding this

Would be great if anyone could shed some light on the issue

Thx

[Michal Kuratczyk]

Hi,

Let me start by reminding you that you should not be using classic mirrored queues.

They were already removed from the main branch and won't be available at all in the next version.

Having said that, as you pointed out, the question applies to all queue types, including streams.

You also know the answer already: yes, for the best performance it's better to be connected to the leader,

at least for publishing. The consumption is not so obvious because quorum queues and streams

support consumption from a follower and therefore spreading consumers across the cluster will

generally yield better results (more uniform distribution of load across the nodes + the leaders

have more resources available to handle the publishers, since publishing has to go through the leader).

So why don't we just always connect to the leader for publishing? Consider just two scenarios:

* a publisher publishes to a fanout exchange, which routes messages to many queues, which can be on different nodes.

  Which node should the publisher be connected to in this case?

* an even simpler scenario - a publisher publishes to a direct exchange with 1 binding per key, so we could check where that

  one queue is, but what if the next message is published with a different routing key and therefore routed to a different

  queue, which happens to be on a different node? Should we keep telling the publisher to reconnect to a different

  node? That would be much worse than what we do right now.

It's not an easy problem to solve. Moreover, the publishing latency is not that critical for many use cases - after all

if you are using a queueing system, you accept the fact that a message can be queued, right? So the fact that it may

take a bit longer to reach the queue in the first place, should not be such a big deal. We discussed some ideas in the

past and some may materialize in the future. For cases where you know which queue the publisher should be collocated

with, we could have some way for the publisher to express that wish, and for RabbitMQ to fulfill it, if possible.

But for more users, the simplicity and flexibility of the current approach (just connect to one of the nodes and everything

will work) is much more important than the lowest possible latency.

In cases that require low latency, you can design your system with the publisher/consumer locality in mind

and/or use a single node. Additionally, in RabbitMQ 4.0, we will introduce a new exchange type,

which only routes messages to local queues: https://www.rabbitmq.com/docs/next/local-random-exchange

It depends on your applications being deployed in a certain way (see the docs), but that's just

the reality of distributed systems and optimising for low latency: there's no magic bullet/toggle to just

"enable low latency".

Best,

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/763d7b15-2ec1-44f3-aedc-dc9657faa558n%40googlegroups.com.

--

Michal

RabbitMQ Team

This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

[Zero Gravity]

Hi

Thank you for the explanation 

Best regards,