私はRabbitmq（とプログラミング）の初心者ですので、これが明らかであれば、事前にご容赦ください。私は、キュー上で動作しているスレッド間で共有するプールを作成していますが、プールで接続やチャネルを使用すべきかどうかはわかりません。rabbitmqの接続またはチャネルをプールする際にパフォーマンスの違いはありますか？
私は実際の作業を行うためにチャネルが必要ですが、接続ごとに1つのチャネル（キューからのスループットの点で）があるというパフォーマンス上の利点はありますか？または、アプリケーションごとに1つの接続を使用して複数のチャネルをプールする方が良いでしょうか？
注：リソースをプールしているため、接続がチャネルよりも高価であることがわかっているため、初期コストは重要な要素ではありません。私はスループットにもっと興味があります。
これはrabbitmq websiteで見つかったので、それは下にあるので、私は以下の関連部分を引用しました。
tl; drバージョンは、アプリケーションごとに1つの接続とスレッドごとに1つの接続が必要であるということです。希望が役立ちます。
接続
AMQP接続は、一般的に長寿命です。 AMQPは、信頼性の高い配信にTCPを使用するアプリケーション レベルのプロトコルです。 AMQP接続 は認証を使用し、TLS（SSL）を使用して保護することができます。 アプリケーションをAMQPブローカに接続する必要がなくなった場合、 が突然基本TCP接続を閉じるのではなく、 がAMQP接続を正常に閉じる必要があります。
チャネル
AMQPブローカーへの複数の接続が必要なアプリケーションがあります。 しかし、多くのTCP接続を同じ時刻に開いておくことは望ましくありません。これは、システムリソースを消費し、ファイアウォールを構成するのが難しくなるからです。 AMQP 0-9-1接続は、「単一のTCP接続を共有する軽量の 接続」と考えることができるチャネルで多重化された です。
処理のために複数のスレッド/プロセスを使用するアプリケーションでは、 スレッド/プロセスごとに新しいチャネルを開き、それらの間でチャネルを共有することは非常に一般的です。特定のチャネル上の
通信は、他のチャネル上の 通信から完全に分離され、したがって、すべてのAMQP方法も クライアントがどのチャネルを把握するために使用するチャンネル番号を運ぶ 方法が（したがって、どのイベントハンドラニーズのためのものです例えば、 ）。
スレッドセーフであるにもかかわらず、スレッドごとに1つのチャネルがあることが推奨されているので、複数のスレッドが1つのチャネルを送信する可能性があります。あなたのアプリケーションの観点からは、スレッドごとに1つのチャンネルを使用することをお勧めします。
さらに、1つのチャンネルにつき消費者が1人であることが推奨されます。
これらはガイドラインに過ぎないため、何が最善のものかを確認するためにいくつかのテストを行う必要があります。
このスレッドにはいくつかの洞察がありますhereとhereです。
これらのすべてのガイドラインにもかかわらず、this postは、複数の接続を持つことでパフォーマンスにほとんど影響しない可能性が高いことを示しています。クライアント側とサーバー側（rabbitmq側）のどちらを話しているのかは具体的ではありませんが、 1つの点として、より多くの接続でより多くのシステムリソースを使用することはもちろんです。これが問題ではない場合、スループットを増やしたい場合は、this postが複数の接続でより多くのスループットを可能にすることを示唆しているので、複数の接続を持つほうがよい場合があります。その理由は、複数のチャネルがあっても、一度に1つのメッセージしか接続を通過しないためです。したがって、大規模なメッセージは接続全体をブロックするか、1つのチャネル上の重要でないメッセージの多くが、同一の接続ではあるが異なるチャネルの重要なメッセージをブロックする可能性があります。もう一度リソースが問題になります。 1つの接続ですべての帯域幅を使い切っている場合、追加の接続を追加すると、1つの接続で2つのチャネルを持つ場合よりもパフォーマンスが向上しません。また、各接続は、より多くのメモリ、CPUとファイルハンドルを使用しますが、スケーリングの際には問題になるかもしれませんが、それは懸念事項ではありません。受け入れ答えに加えて
：あなたが前面にロードバランサ、または短命のDNSのいずれかでのRabbitMQノードのクラスタを持っている場合は
（異なるウサギのノードそれぞれに接続することが可能となります1つのアプリケーションノードが排他的に1つのRabbitMQノードで動作することを意味します。これにより、1つのRabbitMQノードが他のノードよりも多く利用される可能性があります。
上記の他の懸念事項は、パブリッシングと消費がブロッキング操作であり、メッセージをキューに入れることです。より多くの接続があると、各メッセージの処理時間は他のメッセージをブロックしません。2.大きなメッセージは他のメッセージをブロックしていません。
それは小さな接続プールを持つ検討する価値がある理由（心の中で上記の提起リソースの懸念を持つ）です
とあなたが提案するこの小さな接続プールを参照してください、それは提供されているか、私は自分自身を実装する必要がありますか？ – Mahdi
「スレッドごとに1つのチャンネル」は私が持っていないとして（私がかもしれないと言う安全な仮定であるかもしれません自分でどんな研究をしたと私はドキュメントを:)疑う理由はない）が、これは壊れる場合があることを注意してください：
あなたがRabbitMQのDirect reply-toでRPCを使用する場合は、あなたがに同じチャネルを再利用することはできません別のものを使用する RP Cリクエスト。私はgoogle user groupにその詳細については尋ねたと私は（積極的にRabbitMQの開発に関与しているようだ）マイケル・Klishinから得た答えは
直接返信がチャネル共有のいずれかの方法で使用することを意図していないためにということでした。
私はamq.rabbitmq.reply-toは、ボンネットの下に働いていると私はまだ答え（または更新）を待っているかを説明するための彼らのドキュメントを更新するピボタルメールをしました。
「スレッドごとに1つのチャネル」に固執したい場合は、直接応答ではうまくいかないため注意してください。
False - "チャネルスレッドセーフ チャネルインスタンスは複数のスレッドで安全に使用できます。チャンネルへのリクエストはシリアライズされ、一度に1つのスレッドだけがチャンネル上でコマンドを実行できます。それでも、複数のスレッド間で同じチャンネルを共有するのではなく、スレッドごとにチャンネルを使用する方がよいでしょう」APIドキュメントごとに – djechlin
okが編集されました。 1つのコンシューマ、1つのチャネル、1つのスレッド – robthewolf
チャネルはスレッドセーフであるかどうかは、実装によって異なります。Javaのimplは安全ですが、.netは安全ではありません。http://stackoverflow.com/a/17829906/709537 –