Perencanaan Kapasitas & Pengujian Beban

Production incidents often stem from undersized brokers: queues back up, memory alarms fire, and publishers block.

Capacity planning and load testing prevent these surprises.

• Publish and deliver rates (messages/sec)
• Average message size
• Peak queue depth
• Number of connections and channels

RabbitMQ triggers a memory alarm and blocks publishers when memory crosses the high watermark. Size RAM so steady-state stays well below it.

The official rabbitmq-perf-test tool generates configurable publisher and consumer load to benchmark a broker.

Run a test with a fixed publish rate and several consumers.

Vary the payload size to see how throughput changes; larger messages saturate network and disk sooner.

Gradually raise the rate until latency spikes or the broker flow-controls publishers. That inflection point is your practical ceiling; plan to run below it.

When a broker is overwhelmed it applies flow control, slowing fast publishers. Seeing this in tests means you are at capacity.

Benchmark with persistent messages and publisher confirms enabled, since those reflect real reliable workloads and cost throughput.

Each connection and channel consumes resources. Test with a realistic connection count, since thousands of idle connections still cost memory and file descriptors.

• Measure peak rates and add headroom (often 2x)
• Pick node count and instance size from results
• Re-test after every major topology change

Capacity planning sizes a broker from real metrics, and load testing with PerfTest validates it under realistic, persistent, confirmed traffic.

Find the throughput cliff where flow control kicks in, plan to run with headroom below it, and re-test after topology changes.