web-dev-qa-db-ja.com

ZeroMQ、RabbitMQ、Apache Qpidのパフォーマンス比較

アプリケーションに高性能のメッセージバスが必要なので、ZeroMQRabbitMQ、およびApache Qpidのパフォーマンスを評価しています。パフォーマンスを測定するために、メッセージキューの実装のいずれかを使用して10,000メッセージを発行し、これらの10,000メッセージを消費するために同じマシンで別のプロセスを実行するテストプログラムを実行しています。次に、最初に発行されたメッセージと最後に受信されたメッセージの時間差を記録します。

以下は、比較に使用した設定です。

  1. RabbitMQ:デフォルト構成の「ファンアウト」タイプの交換とキューを使用しました。 RabbitMQ Cクライアントライブラリを使用しました。
  2. ZeroMQ:パブリッシャーはtcp://localhost:port1ソケットでZMQ_Pushに公開し、ブローカーはtcp://localhost:port1をリッスンし、tcp:// localhost:port2にメッセージを再送信し、コンシューマーはリッスンしますtcp://localhost:port2ZMQ_PULLソケットを使用。 ZeroMQでピアツーピア通信の代わりにブローカーを使用して、ブローカーを使用する他のメッセージキュー実装とパフォーマンスの比較を公平にします。
  3. Qpid C++メッセージブローカー:「ファンアウト」タイプの交換とキューをデフォルト構成で使用しました。 Qpid C++クライアントライブラリを使用しました。

パフォーマンスの結果は次のとおりです。

  1. RabbitMQ:10,000メッセージを受信するのに約1秒かかります。
  2. ZeroMQ:10,000メッセージを受信するのに約15ミリ秒かかります。
  3. Qpid:10,000メッセージを受信するのに約4秒かかります。

質問:

  1. 誰かがメッセージキュー間で同様のパフォーマンス比較を実行しましたか?それから私の結果をあなたの結果と比較したい。
  2. パフォーマンスを向上させるためにRabbitMQまたはQpidを調整する方法はありますか?

注:

テストは、2つのプロセッサが割り当てられた仮想マシンで実行されました。結果はハードウェアによって異なる場合がありますが、主にMQ製品の相対的なパフォーマンスに関心があります。

76
ahsankhan

RabbitMQは、おそらくこれらのメッセージの永続化を行っています。永続化を行わないようにするには、メッセージの優先度または別のオプションを設定する必要があると思います。その場合、パフォーマンスは10倍に向上します。 AMQPブローカーを介して、少なくとも10万メッセージ/秒を期待する必要があります。 OpenAMQでは、最大30万メッセージ/秒のパフォーマンスが得られました。

AMQPwasは速度を重視して設計されています(たとえば、メッセージをルーティングするためにアンパックしません)が、ZeroMQは重要な方法で設計されているだけです。例えば。ブローカーなしでノードを接続することにより、ホップを削除します。 AMQPクライアントスタックよりも優れた非同期I/Oを実行します。より積極的なメッセージのバッチ処理を行います。おそらくZeroMQの構築に費やされた時間の60%がパフォーマンスチューニングに費やされました。とても大変でした。偶然ではありません。

私がやりたいことの1つは、忙しすぎて、ZeroMQの上にAMQPのようなブローカーを再作成することです。ここに最初の層があります: http://rfc.zeromq.org/spec:15 。スタック全体はRestMSのように機能し、トランスポートとセマンティクスは2つのレイヤーに分けられます。 AMQP/0.9.1とほぼ同じ機能を提供します(そして意味的に相互運用可能です)が、かなり高速です。

93
Pieter Hintjens

うーん、もちろんZeroMQはより高速になります。他の2つが提供する多くのブローカーベースの機能を持つように設計されています。 ZeroMQサイト には、ブローカーとブローカーレスメッセージングの優れた比較と、両方の欠点と利点があります。

RabbitMQブログ

RabbitMQと0MQは、メッセージングのさまざまな側面に焦点を当てています。 0MQは、メッセージがネットワークを介してどのように転送されるかに焦点を当てています。一方、RabbitMQは、メッセージの保存、フィルタリング、および監視方法に焦点を当てています。

(RabbitMQでZeroMQを使用することについても説明しているため、上記のRabbitMQの投稿も気に入っています)

だから、私が言いたいのは、あなたの要件に最適な技術を決めるべきだということです。唯一の要件が速度である場合、ZeroMQ。ただし、メッセージの永続性、フィルタリング、監視、フェイルオーバーなどの他の側面が必要な場合は、RabbitMQとQpidの検討を開始する必要があります。

32
Steve Casey

ZeroMQでピアツーピア通信の代わりにブローカーを使用して、ブローカーを使用する他のメッセージキューの実装とパフォーマンスの比較を公平にします。

なぜそれをしたいのかわからない-パフォーマンスだけが気になるのであれば、競技場のレベルを上げる必要はありません。永続性、フィルタリングなどを気にしない場合、なぜ代価を払うのですか?

また、VMでベンチマークを実行することに非常に不安を感じています-明らかでない方法で結果に影響を与える可能性のある余分なレイヤーがたくさんあります。 (もちろん、VMで実際のシステムを実行する予定がない限り、この場合は非常に有効な方法です)。

4
WallStProg

C++/qpidをテストしました

2つの異なるマシン間で1秒間に50000のメッセージをキューに入れずに送信しました。

ファンアウトを使用せず、単純な交換(非永続メッセージ)

持続メッセージを使用していますか?メッセージを解析していますか?

0MQにはメッセージ構造体がないため、そうではないと思います。

ブローカーが主にアイドル状態の場合、おそらく送信側と受信側でプリフェッチを構成していない可能性があります。これは、多くのメッセージを送信するために非常に重要です。

3
joseluis

RabbitMQとSocketPro( http://www.udaparts.com/ )サイトの永続メッセージキューを比較しました http://www.udaparts.com/document/articles/ fastsocketpro.htm すべてのソースコード。 RabbitMQについて得られた結果は次のとおりです。

同じマシンのエンキューとデキュー:

"こんにちは世界" -
エンキュー:1秒あたり30000メッセージ。
デキュー:7000メッセージ/秒。

1024バイトのテキスト-
エンキュー:1秒あたり11000メッセージ。
デキュー:1秒あたり7000メッセージ。

10 * 1024バイトのテキスト-
エンキュー:1秒あたり4000メッセージ。
デキュー:1秒あたり4000メッセージ。

ネットワーク帯域幅100 mbpsのクロスマシンエンキューおよびデキュー:

"こんにちは世界" -
エンキュー:1秒あたり28000メッセージ。
デキュー:1900メッセージ/秒。

1024バイトのテキスト-
エンキュー:8000メッセージ/秒。
デキュー:1000メッセージ/秒。

10 * 1024バイトのテキスト-
エンキュー:1秒あたり800メッセージ。
デキュー:1秒あたり700メッセージ。

1
user4006286

送信者と受信者に100などの値でプリフェッチを設定してみてください。送信者だけをプリフェッチするだけでは不十分です。

0
jale

ZeroMQの上に構築されたオープンソースのメッセージバスを開発しました-最初はQpidを置き換えるためにこれを行いました。ブローカーレスなので完全に公正な比較ですが、ブローカーソリューションと同じ機能を提供します。

私たちの見出しのパフォーマンスの数値は、2台のマシン間で1秒あたり140Kメッセージですが、ここで詳細を見ることができます: https://github.com/Abc-Arbitrage/Zebus/wiki/Performance

0
Slugart