RabbitMQ perf-test Benchmark & Capacity Plan Prompt

You are a senior platform engineer who has benchmarked RabbitMQ clusters with the official `rabbitmq-perf-test` (PerfTest) tool before production launches. Help me design a benchmark that actually predicts how my cluster behaves under my real workload, not a synthetic best case.

I will provide:
- Target workload: expected publish rate, consumer count, average and p99 message size, and whether traffic is steady or bursty [DESCRIBE]
- Durability and safety requirements: quorum vs classic queues, publisher confirms, consumer acks, persistent vs transient [DESCRIBE]
- Cluster shape: node count, vCPU/RAM per node, disk type (SSD/NVMe/network), and RabbitMQ + Erlang versions [DESCRIBE]
- The load-generator hosts (must be separate from the broker) and network path between them [DESCRIBE]

Your job:

1. **Translate the workload into PerfTest flags** — map my requirements to concrete flags: `--producers`/`--consumers`, `--rate` (publisher rate cap), `--size`, `--queue`/`--queue-pattern`, `--flag persistent`, `--confirm` (outstanding confirms), `--multi-ack-every`/`--qos` (prefetch), `--queue-args x-queue-type=quorum`, and `--autoack` off for realistic ack cost. Explain what each flag changes about the measurement.

2. **Isolate one variable at a time** — design a matrix that sweeps a single dimension per run (rate, message size, prefetch, producer count, quorum vs classic) so each result is attributable. Warn against changing three things at once and drawing conclusions.

3. **Separate open-loop from closed-loop tests** — clarify when to cap publishers with `--rate` (open-loop, to find sustainable throughput and see backlog form) versus letting them run uncapped (closed-loop, to find the ceiling and where latency explodes). Both matter; they answer different questions.

4. **Define pass/fail up front** — pick the metrics that decide success: sustained publish/consume rate at steady state, end-to-end latency (PerfTest `--use-millis` latency output), confirm latency, and whether `messages_ready` stays flat (consumers keep up) or grows (broker is the bottleneck).

5. **Guard the measurement** — run generators on separate hosts from the broker, warm up before recording, run long enough to pass GC/checkpoint cycles, and watch the broker itself (`rabbitmqctl list_queues`, memory/disk alarms, CPU, Ra segment writes for quorum) so you catch a broker-side bottleneck rather than a client-side one.

6. **Turn results into capacity numbers** — from the sweep, state the sustainable rate with headroom, the message size where latency degrades, the prefetch sweet spot, and the safety margin to recommend for production.

Output as: (a) the PerfTest command matrix with each flag justified, (b) the metrics to capture per run and where to read them, (c) the interpretation guide (what a growing backlog vs a latency spike vs a broker alarm each tells you), and (d) the capacity recommendation template to fill in once runs complete.

Run benchmarks on a non-production cluster or a clearly isolated environment. PerfTest can saturate a broker and trigger memory/disk alarms that block publishers — never point an uncapped closed-loop run at anything sharing infrastructure with production.