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

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

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

  1. RabbitMQ: I used a "fanout" type exchange and a queue with default configuration. I used the RabbitMQ C client library.
  2. ZeroMQ: My publisher publises to tcp://localhost:port1 with ZMQ_PUSH socket, My broker listens on tcp://localhost:port1 and resends the message to tcp://localhost:port2 and my consumer listens on tcp://localhost:port2 using ZMQ_PULL socket. I am using a broker instead of peer to to peer communication in ZeroMQ to to make the performance comparison fair to other message queue implementation that uses brokers.
  3. Qpid C++ message broker: I used a "fanout" type exchange and a queue with default configuration. I used the Qpid C++ client library.

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

  1. RabbitMQ: it takes about 1 second to receive 10,000 messages.
  2. ZeroMQ: It takes about 15 milli seconds to receive 10,000 messages.
  3. Qpid: It takes about 4 seconds to receive 10,000 messages.

質問：

  1. 誰かにメッセージキュー間で同様のパフォーマンス比較を実行させますか？次に、結果をあなたのものと比較したいのです。
  2. パフォーマンスを向上させるために RabbitMQ や Qpid をチューニングできる方法はありますか？

注：

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

68
追加された 編集された
ビュー: 13
源
ro ru fr es pt de hi bn ar kk uz be tr uk
各メッセージは、このテストを行ったときのバイト数でしたか？
追加された 著者 arsenal, 源
ZeroMQ の父親であるMartin Sustrikによって進化した nanomsg - もう一つの子孫を試してみてください。読むのが良い場所は>>> nanomsg.org/documentation-zeromq.html です。
追加された 著者 user3666197, 源
2013年4月10日付けの比較は次のとおりです。 x-aeon.com/wp/2013/04/10/…
追加された 著者 Daniel F, 源
RabbitMQ、Kafka、HornetQ、SQS、Mongoベースの複製キューのパフォーマンスの比較： warski.org/blog/2014/07/…
追加された 著者 adamw, 源
RabbitMQ、Kafka、HornetQ、ActiveMQ、SQS、Mongoの性能比較の最新バージョンはここにあります： softwaremill.com/mqperf
追加された 著者 adamw, 源
私は数ヶ月前に同様の結果を出して簡単なテストを行った。そして、私はRabbitMQまたはQpidを使って作業しているときにシステムがかなりアイドル状態にあることに気付きました。何かが間違っていなければならないと思う。
追加された 著者 Gary Shi, 源
「RabbitMQ：10,000メッセージを受信するのに約12秒かかります。」 - 私たち自身のテストでは、CPUあたり20-25,000/secのイングレスが定期的に表示されます。だから、あなたは何か間違っている、または遅いクライアントを使用しています。 rabbitmq-discussにメールで質問してみましたか？
追加された 著者 user1021067, 源

8 答え

RabbitMQはおそらくそれらのメッセージに対して永続化を行っています。私は、永続性を持たないためにメッセージの優先度や別のオプションをメッセージに設定する必要があると思います。パフォーマンスは10倍向上します。 AMQPブローカを使用して、毎秒少なくとも100,000メッセージが必要です。 OpenAMQでは、最大300Kメッセージ/秒のパフォーマンスが得られました。

AMQPは 高速化のために設計されていましたが（例えば、メッセージを配送するためにメッセージを解凍しません）、ZeroMQは単に主要な方法で設計されています。例えば。ブローカなしでノードを接続してホップを削除します。 AMQPクライアントスタックよりも非同期I/Oが優れています。より積極的なメッセージバッチ処理を行います。おそらく、ZeroMQを構築するのに費やした時間の60％がパフォーマンスチューニングに入ったでしょう。それは非常に難しい作業でした。それは偶然により速くはありません。

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

84
追加された
源
RIPメイト、あなたは素晴らしいものを作りました
追加された 著者 RPGillespie, 源
私たちは誰かがより良い解決策を見つけてから@pieter btwを出すまで、rabbitmqを使い続けます。それは私に偉大な特許の話を思い出させる[1]。 [1] youtube.com/watch?v=5QqbDyZ8Eu4
追加された 著者 Kunthar, 源

Hmm, of course ZeroMQ will be faster, it is designed to be and does not have a lot of the broker based functionality that the other two provide. The ZeroMQ site has a wonderful comparison of broker vs brokerless messaging and drawbacks & advantages of both.

RabbitMQ Blog:

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

（また、上記のRabbitMQの記事は、RabbitMQでZeroMQを使用する方法についても説明しています）

So, what I'm trying to say is that you should decide on the tech that best fits your requirements. If the only requirement is speed, ZeroMQ. But if you need other aspects such as persistence of messages, filtering, monitoring, failover, etc well, then that's when u need to start considering RabbitMQ & Qpid.

31
追加された
源
はい、私はそれがブローカーを持っていないとブローカーとブローカーの記事にリンクされていると述べました。それは明らかではなかったか？また、2011年にこの回答を投稿したとき、2014年10月に登場したMalamuteはありませんでした
追加された 著者 Steve Casey, 源
ZeroMQにはブローカーがありません。アプリケーションの全体設計の一部としてブローカーを設計すると、ブローカーは、ゼロ点でリッスンし、宛先に応じてメッセージをルーティングします。 ZeroMQはジョブを1つしか実行せず、メッセージキューイングも非常にうまく機能します。 ZeroMQの人々によってZeroMQのために設計されたブローカー実装であるMalamuteがありますが、それはZeroMQの一部ではありません。 ZeroMQと一緒にインストールすることができるサービスです。独自のプロセスでも、メッセージブローカー専用の別のボックスにもインストールできます。それはそれ自身のプロジェクトです。 github.com/zeromq/malamute
追加された 著者 user356540, 源

ブローカを使用する他のメッセージキューの実装とパフォーマンスの比較を公正に行うため、ZeroMQのピアツーピア通信ではなくブローカを使用しています。

なぜそれをしたいのか分かりません。あなたが気にしているのはパフォーマンスだけであれば、プレーフィールドレベルを作る必要はありません。永続性、フィルタリングなどを気にしない場合は、なぜ価格を支払うのですか？

私はVM上でベンチマークを実行することにも非常に注意しています - 明らかではない方法で結果に影響を与える余分なレイヤーがたくさんあります。 （実際のシステムをVM上で実行する予定がない限り、もちろんその場合は非常に有効な方法です）。

4
追加された
源

私はc ++/qpidをテストしました

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

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

永続メッセージを使用していますか？ あなたはメッセージを解析していますか？

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

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

3
追加された
源
私は耐久性のないキューを使用している、私はメッセージを解析しない、実際に私はすべての3つのキューの実験のためのメッセージを生成するために同じコードを使用しています。交換タイプをダイレクトに変更しても、パフォーマンスには影響しませんでした。また、送信側フロー制御（api sender.SetCapaclity（8））を使用した後、タイミングが悪化しました。送信者フロー制御なしでは、キューは無限に拡大しているように見えます。時間を測定するときに、すべてのメッセージを受信するまで待ち、キューが完全に空になっていますか？
追加された 著者 ahsankhan, 源
私は、qpid-perftestプログラムがQpidの「古いメッセージングApis」を使用していることを発見しました。私のテストで古いApisに切り替えるとパフォーマンスが10倍向上しました。
追加された 著者 ahsankhan, 源

私はあなたがセロリを使用すると、Rabbitmqのパフォーマンスが向上すると思います

3
追加された
源
OPはPythonの使用については言及していません。偉大な図書館ではセロリが黒い魔法ではなく、rabbitmqを使用するだけで高速化することはできません。
追加された 著者 gawry, 源

RabbitMQとSocketPro（ http://www.udaparts.com/ ）の永続メッセージキューを比較しました。サイト

>すべてのソースコードで。 RabbitMQで得られた結果は次のとおりです。

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

"Hello world" -
  エンキュー：毎秒30000メッセージ;
  デキュー：毎秒7000メッセージ。

     

1024バイトのテキスト -
  エンキュー：毎秒11000メッセージ;
  デキュー：毎秒7000メッセージ。

     

10 * 1024バイトのテキスト -
  エンキュー：4000メッセージ/秒;
  デキュー：毎秒4000メッセージ。

100Mbpsのネットワーク帯域幅を使用したクロスマシンエンキューおよびデキュー：

"Hello world" -
  エンキュー：毎秒28000メッセージ;
  デキュー：毎秒1900メッセージ。

     

1024バイトのテキスト -
  エンキュー：毎秒8000メッセージ;
  デキュー：1秒あたり1000メッセージ。

     

10 * 1024バイトのテキスト -
  エンキュー：800メッセージ/秒;
  デキュー：毎秒700メッセージ。

1
追加された
源

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

Our headline performance figure is 140K msgs per second between two machines but you can see more detail here: https://github.com/Abc-Arbitrage/Zebus/wiki/Performance

0
追加された
源

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

0
追加された
源
Fro qpid、私はReceiver.setCapacity（100）がレシーバのプリフェッチを設定するという印象を持っていました。 Aferは、 "新しいqpid api"とQpidの古いメッセージングApiに似たパフォーマンスbacameを使用してコードのパフォーマンスを10倍向上させました。投稿を結果で更新しました。しかし、Qpidはまだrabbitmqより4倍遅いようです。
追加された 著者 ahsankhan, 源