rabbitmqのプール接続またはチャネル間にパフォーマンスの違いはありますか？
私はRabbitmq（およびプログラミング）の初心者なので、これが明らかな場合は事前に申し訳ありません。キューで動作しているスレッド間で共有するプールを作成していますが、プールで接続またはチャネルを使用する必要があるかどうかわかりません。
実際の作業を行うためにチャネルが必要であることは知っていますが、接続ごとに1つのチャネルを持つことのパフォーマンス上の利点はありますか（キューからのスループットの増加に関して）または、アプリケーションごとに単一の接続を使用し、多くのチャネルをプールする方が良いでしょうか？
注：リソースをプールしているため、接続はチャネルよりも高価であることがわかっているため、初期コストは要因ではありません。スループットにもっと興味があります。
これは rabbitmqウェブサイト で見つけました。下にあるので、関連する部分を以下に引用しました。
Tl; drバージョンでは、アプリケーションごとに1つの接続、スレッドごとに1つのチャネルが必要です。それが役に立てば幸いです。
接続
AMQP接続は通常、長命です。 AMQPは、信頼できる配信のためにTCPを使用するアプリケーションレベルのプロトコルです。AMQP接続は認証を使用し、TLS（SSL）を使用して保護できます。アプリケーションをAMQPブローカーに接続する必要がなくなると、基礎となるTCP接続を突然閉じるのではなく、AMQP接続を適切に閉じます。
チャンネル
一部のアプリケーションでは、AMQPブローカーへの複数の接続が必要です。ただし、多くのTCP接続を同時に開いたままにすると、システムリソースが消費され、ファイアウォールの構成が難しくなるため、望ましくありません。AMQP0-9-1接続はチャネルと多重化されます「単一のTCP接続を共有する軽量接続」と考えることができます。
処理に複数のスレッド/プロセスを使用するアプリケーションでは、スレッド/プロセスごとに新しいチャネルを開き、それらの間でチャネルを共有しないことが非常に一般的です。
特定のチャネルでの通信は別のチャネルでの通信とは完全に分離されているため、すべてのAMQPメソッドは、クライアントがメソッドの対象となるチャネル（したがって、たとえば、どのイベントハンドラーを呼び出す必要があるか）を特定するために使用するチャネル番号も保持します。
スレッドセーフであるにもかかわらず、スレッドごとに1つのチャネルがあるため、1つのチャネルを介して複数のスレッドを送信することをお勧めします。アプリケーションに関しては、スレッドごとに1つのチャネルを使用することをお勧めします。
さらに、チャネルごとに1人のコンシューマーのみを使用することをお勧めします。
これらはあくまでもガイドラインであるため、テストを行って最適な結果を確認する必要があります。
このスレッドにはいくつかの洞察があります here および here 。
これらのすべてのガイドラインにもかかわらず この投稿 は、複数の接続を持つことでパフォーマンスにほとんど影響しないことを示唆しています。クライアント側とサーバー（rabbitmq）側のどちらであるかは明確ではありませんが。もちろん、より多くのシステムリソースをより多くの接続で使用するという1つのポイントがあります。これが問題ではなく、スループットを増やしたい場合は、複数の接続を使用した方がよい場合があります。 この投稿 は、複数の接続によりスループットが向上することを示しています。その理由は、複数のチャネルがある場合でも、一度に1つのメッセージのみが接続を通過するためです。したがって、大きなメッセージは接続全体をブロックするか、1つのチャネル上の重要でないメッセージの多くが、同じ接続で異なるチャネルの重要なメッセージをブロックする場合があります。繰り返しますが、リソースは問題です。 1つの接続ですべての帯域幅を使い果たしている場合、追加の接続を追加しても、1つの接続で2つのチャネルを使用するよりもパフォーマンスは向上しません。また、各接続はより多くのメモリ、CPU、およびファイルハンドルを使用しますが、スケーリング時には問題になる可能性がありますが、それは問題にならないでしょう。
受け入れられた答えに加えて：
RabbitMQノードのクラスターの前にロードバランサーまたは短命のDNS（毎回異なるウサギノードに接続できるようにする）がある場合、1つの長命の接続はそれを意味しますアプリケーションノードは、単一のRabbitMQノードと排他的に機能します。これにより、1つのRabbitMQノードが他のノードよりも頻繁に使用される可能性があります。
上記の他の懸念は、パブリッシュとコンシュームがブロック操作であり、メッセージのキューイングにつながることです。接続を増やすことにより、1。各メッセージの処理時間が他のメッセージをブロックしないようにします。2。大きなメッセージが他のメッセージをブロックしないようにします。
そのため、小さな接続プールを持つことを検討する価値があります（上記で挙げたリソースの懸念を念頭に置いてください）
「スレッドごとに1つのチャネル」mightは安全な仮定です（私は自分で調査を行っていないので、疑う理由はありませんドキュメント:)）しかし、これが壊れる場合があることに注意してください：
RabbitMQ Direct reply-to でRPCを使用する場合、sameチャネルを再利用してanotherRPCリクエスト。 google user group で詳細を尋ねたところ、Michael Klishin（RabbitMQ開発に積極的に関与しているようです）から得た答えは
Direct Reply toは、どちらの方法でもチャネル共有で使用することを意図したものではありません。
Pivotalにメールして、ドキュメントを更新して説明しますhowamq.rabbitmq.reply-toが内部で動作しており、私はまだ回答（または更新）を待っています。
したがって、「スレッドごとに1つのチャネル」に固執したい場合は、直接返信ではうまく機能しないので注意してください。