durable vs. transient queues

[Nikos Skalis]

hi guys,

i know that durability of a queue does not make messages that are routed to that queue durable. if broker is taken down and then brought back up, durable queue will be re-declared during broker startup.

but what i would to ask you is; performance-wise is there any difference between durable and transient queues ?

or durability in the queue context is only about the configuration of the broker ?

Nikos

[Michael Klishin]

On 10 Sep 2015 at 21:28:53, Nikos Skalis (nskalis....@gmail.com) wrote:
> but what i would to ask you is; performance-wise is there any
> difference between durable and transient queues ?
> or durability in the queue context is only about the configuration
> of the broker ?

There is some but there is no an easy “yes” or “no” answer if you ask me.

Transient messages will be moved to disk when a node is under memory pressure.
Of course, not moving messages to disk when there’s RAM available should in
theory lead to better throughput and possibly lower latency, however, in practices
things are a lot more nuanced.

So you will see somewhat higher throughput with transient messages and/or non-durable
queues but not particularly significant. There are also RAM vs. disk nodes that determine
how metadata about queues, bindings, exchanges is stored. 99% of the time you don’t
need RAM nodes but some users with very high binding churn found them useful. 
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[Laing, Michael]

Another nuance we found is that on restart of a node or cluster: the contents of a durable queue could be unpredictable, and also restart could be much slower than anticipated - even though our standards force transient messages everywhere.

I say "could be" because we only saw this happen when a node or cluster had been severely stressed and then went down hard.

This event occurred on a regional core cluster (Dublin actually) so it was a major issue for us. No outage occurred because other regions took up the load immediately - no one noticed but us.

However, as a result we changed our standards to require that all queues be created as transient and this solved that problem. Our apps each assert the resources they need as a "best practice". On restart of a failed node or cluster, the status of a queue in our system is completely predictable: it doesn't exist.

It may be true that more modern RabbitMQ versions alleviate the issue, but our best practice remains in place.

ml

--
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 post to this group, send an email to rabbitm...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Nikos Skalis]

Thank you guys of the input. It is much appreciated.