誰かがrabbitmqの合理的なスケールの数値/制限（「平均的な」ハードウェア、fwiw）の方向を教えてくれたり、パフォーマンスの経験を投稿してくれたりしてくれればありがたいです。私は、キューの数、キューのサブスクライバーの数、ファンアウトキューに数百または数千のリスナーがいることのパフォーマンスへの影響、大容量環境でウサギを実行している可能性のあるハードナンバーの容量を取得しようとしています。
回答:
まず、リスト内のどのアイテムにスケーリング制限があり、ヒットしていないかを理解する必要があります。この一部は実装に依存しているため、RabbitMQ in Actionの本のように、内部を読むのに役立ちます。
キューの数は、RAMによって制限されます。一方、RabbitMQはメッセージをディスクに自動的にページアウトするため、再生中のメッセージの数はRAMによって制限されません。私が注意を払っていなかったときに、開発サーバーで偶然約800万件のメッセージが再生されました。
メッセージのサイズに制限もありませんが、1つのメッセージのサイズが512Kを超える場合は、本当によく考えてください。最終的には、メモリキャッシュを使用してアプリケーション間で大きなオブジェクトを渡し、memcacheキーを含む小さな制御メッセージのみを送信しました。ただし、本当に必要な場合は、巨大なJPEGとJARファイルなどのバイナリオブジェクトをメッセージとして送信できます。
サブスクライバーは少なくとも1つのTCPソケットを開く必要があるため、サブスクライバーの数はOSの制限です。もちろん、これはほとんどのOSで調整可能であるため、走行距離はさまざまであるため、モデルをテストする必要があります。JMETERを使用してWebアプリケーションの負荷テストを行っており、このAMQPプラグインhttps://github.com/jlavallee/JMeter-Rabbit-AMQPを発見しましたが、まだ使用していません。いずれにせよ、これは、ハードウェア（またはVM構成）が合理的に処理するものをすぐに示す一種のテストです。
あなたが持っている唯一の困難なことは、ファンアウトキューに対して多数の消費者をテストすることです。代わりにトピック交換を使用して比較し、コンシューマーが同じ最終結果を達成するワイルドカード（*）バインディングキーを使用してサブスクライブすることもできます。できるだけ多くの異なるマシンでこのテストを実行して、コンシューマプロセスを実行している単一のサーバーが原因で何らかの形でボトルネックに陥っていないことを確認してください。Jmeterプラグインは、消費者をシミュレートするのにも役立つようです。
これは実際に答えられる質問ではありません-あまりにも多くの要因があります（「平均」ハードウェアの移動する定義、キュー内のメッセージのサイズ、消費者の数、ポーリングの頻度/メッセージの処理速度など） 。）。環境をベンチマークする必要があります。
とはいえ、RabbitMQのパフォーマンスに関するこれらの議論のいくつかをチェックしてください（Rabbitに期待できることを確認するために、インストールのベンチマークを行う方法に関するいくつかのアイデアを含みます）