RabbitMQ performance is a workload property. Message size, persistence, confirms, acknowledgments, routing, queue type, replicas, consumers, prefetch, storage, network, failures, and latency targets interact. There is no universal messages-per-second result or tuning value.

Define a representative benchmark

Record RabbitMQ/Erlang and client versions, topology, queue type, node/zone layout, storage, network, message-size distribution, durability, confirm and acknowledgment modes, routing, producer/consumer counts, prefetch, processing time, retry behavior, and test duration. Measure end-to-end p50/p95/p99 latency, publish/consume rate, errors, redeliveries, loss/duplicates, queue depth, resources, and recovery.

Choose queue type deliberately

Quorum queues are the replicated, data-safety-oriented default for many durable workloads in current RabbitMQ guidance. Classic queues and streams serve different requirements. Queue type, replication, delivery limits, priority, retention, and feature support must match the use case and release.

Balance safety and throughput

Publisher confirms establish broker acceptance according to the selected topology; consumer acknowledgments establish processing responsibility. Neither provides end-to-end exactly-once effects. Make consumers idempotent where duplicates are possible and define reconciliation for consequential workflows.

Batching and asynchronous confirms can increase throughput while changing latency and outstanding-risk windows. Test connection loss, channel closure, confirm timeout, consumer crash, redelivery, and leader failover.

Tune consumers from processing behavior

Prefetch limits unacknowledged deliveries. Too low can underutilize consumers; too high can increase memory, unfairness, and recovery work. Measure consumer capacity, processing latency, acknowledgment delay, redelivery, and queue growth across realistic variability.

Scale topology, not just nodes

A single queue has a leader and finite throughput. Adding nodes does not automatically accelerate one hot queue. Partition workload across well-chosen queues when ordering and routing permit, avoid unbounded dynamic queue creation, and test rebalance, node loss, network partition, and zone failure.

Monitor decisions and alarms

  • Publish/delivery/ack/confirm rates and latency.
  • Ready and unacknowledged messages, redeliveries, consumer capacity, and connection/channel churn.
  • Memory/disk alarms, file descriptors, CPU, storage latency, network, Erlang process/mailbox pressure, and node health.
  • Quorum membership, unavailable queues, leader changes, synchronization/recovery, and partitions.

Alert from service objectives and sustained symptoms, not one universal threshold. Load-test monitoring itself and preserve capacity for recovery.

Change safely

  1. Validate semantics and baseline.
  2. Change one factor.
  3. Run steady-state, burst, soak, and failure phases.
  4. Compare percentiles, correctness, resources, and recovery.
  5. Canary the change and retain rollback.

Secure the cluster with RabbitMQ security, design retry/dead-letter paths, and keep routing bounded using advanced routing patterns.

Originally published December 10, 2015; technically reviewed and substantially updated September 4, 2026.