In our documentation (e.g., [1]) there are general statements like:

"When brokers are connected to form a cluster, AMQ Broker automatically balances the message load between the brokers. This ensures that the cluster can maintain high message throughput. "

Statements like this don't make a strong claim that clustering will improve throughput, but they are read that way by customers. We are, unintentionally, sending a message that a cluster will necessarily offer better throughput than a single broker, when that isn't the case.

In fact, usage models that lead to messages being stored on multiple brokers can significantly reduce throughput, just because synchronous disk writes are so slow, compared to everything else.

Our documentation (either here or elsewhere) should make it clearer what the circumstances are, in which customers can expect improved throughput by adding more brokers to an installation. In general, situations where broker CPU or memory usage are the limiting factors are most likely to see improvements with additional brokers. Situations where disk I/O is the limiting factor are likely to see the least improvement, or even a reduction. However, it's not easy to translate these general principles into specific configurations.

[1] https://access.redhat.com/documentation/en-us/red_hat_amq/7.7/html-single/configuring_amq_broker/index#how-broker-clusters-balance-message-load-configuring