3

ActiveMQ で Openwire と AMQP を使用し、スループットに大きな変動がある場合のパフォーマンス ベンチマークを実行しようとしています。

Openwire の使用

永続的なメッセージ サイズ: 43 バイト、圧縮なし、200 の同時接続、約 9006 メッセージ/秒のスループット。

永続的なメッセージ サイズ: 1580 バイ、圧縮なし、200 の同時接続、約 3678.86 メッセージ/秒のスループット。

5% 未満のCPU にはあまり負荷がかからないため、圧縮を使用してスループットを向上させることができますが、それは別の話です。

AMQP 1.0 の使用

永続的なメッセージ サイズ: 43 バイト、圧縮なし、200 の同時接続、約 12.8 メッセージ/秒のスループット。

永続的なメッセージ サイズ: 1580 バイ、圧縮なし、200 の同時接続、約 11.9 メッセージ/秒のスループット。

私たちの構成は次のとおりです

**Client**
    - JMeter 2.11 using Apache QPid 0.28 as AMQP 1.0 client
    - Java 1.7
    - Ubuntu 12.04 LTS Quad Core 2.0 GHz,7GB RAM, 512 KB Cache

**Broker**
    - ActiveMQ 5.10 with KahaDB, using LevelDB didn't give much different numbers
    - Java 1.7
    - Ubuntu 12.04 LTS Quad Core 2.0 GHz,7GB RAM, 512 KB Cache

チューニング作業:

私は次を見ました

Openwire の場合、Broker 側で tcp を nio に変更

<transportConnector name="openwire" uri="nio://0.0.0.0:61616?maximumConnections=1000&amp;wireFormat.tcpNoDelayEnabled=true&amp;wireFormat.maxFrameSize=104857600"/>

On Client side url was as
    tcp://<broker ip>:61616?jms.useAsyncSend=true

AMQP 1.0 の場合、ブローカー側で nio に変更し、url にいくつかのオプションを追加しましたが、明らかな効果はありません

<transportConnector name="amqp" uri="amqp+nio://0.0.0.0:5672?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>

On Client side
    connectionFactory = amqp://username:password@<broker ip>:5672?remote-host=default

Openwire で利用可能なすべてのチューニング オプションは amqp では利用できません。特に jms.useAsyncSend=true を使用するプロデューサーでは、もちろん ack の信頼性は低くなりますが、パフォーマンスが大幅に向上しました。デフォルトでは、amqp を使用したメッセージの送信はデフォルトで非同期モードになっていることがわかりました。どうやら数字は、同期モードで処理されている可能性があることを示していますか?

ここに私がすでに調べているリンクのいくつかがあります

更新 1:

Tim が以下で指摘したように、私の比較は間違っていました。私は Openwire に Async.Send を使用し、AMQP 1.0 に Sync.Send を使用していました。AMQP 1.0 がデフォルトで Async.Send を使用するというのは私の誤解でした。Robbie は、持続メッセージには当てはまらないと指摘しました。これが正しい比較数値です

Openwire Persistent メッセージ サイズを使用した同期送信: 43 バイト、圧縮なし、200 の同時接続、100,000 メッセージ カウント、約 13.1 メッセージ/秒のスループット。

永続的なメッセージ サイズ: 1580 バイ、圧縮なし、200 の同時接続、100,000 メッセージ カウント、約 13.1 メッセージ/秒のスループット。

AMQP 1.0 パーシステント メッセージ サイズを使用した同期送信: 43 バイ、圧縮なし、200 の同時接続、100,000 メッセージ カウント、約 12.8 メッセージ/秒のスループット。

永続的なメッセージ サイズ: 1580 バイ、圧縮なし、200 の同時接続、100,000 メッセージ カウント、約 11.9 メッセージ/秒のスループット。

Openwire Persistent メッセージ サイズを使用した Async.Send: 43 バイト、圧縮なし、200 の同時接続、100,000 メッセージ数、約 9006 メッセージ/秒のスループット。

永続的なメッセージ サイズ: 1580 バイ、圧縮なし、200 の同時接続、100,000 メッセージ カウント、約 3678.86 メッセージ/秒のスループット。

AMQP 1.0 Persistent メッセージ サイズを使用した Async.Send: 43 バイ、圧縮なし、200 の同時接続、100,000 メッセージ カウント、約 21.7 メッセージ/秒のスループット。

永続的なメッセージ サイズ: 1580 バイ、圧縮なし、200 の同時接続、100,000 メッセージ カウント、約 21.2 メッセージ/秒のスループット。

ノート：

Async.Send メッセージの配信は保証されていませんが、Openwire を使用すると常に 100,000 件のメッセージをすべて受信しましたが、AMQP 1.0 では約 25% のメッセージが失われました。

AMQP 1.0 Async.Send の数値は、まだ Openwire Async.Send の数値に近くありません。他の提案はありますか？

ご協力いただきありがとうございます。

4

2 に答える 2

1

現時点では、AMQP のパフォーマンスを改善するためにブローカー側でできることはあまりありません。ActiveMQ クライアントで同期送信を無効にしているため、ここでは真の比較を行っていないことに注意してください。これにより、プロデューサーの配信が保証されなくなります。この方法でそれらを比較したい場合は、QPid JMS クライアントもこの方法でメッセージを送信するようにしてください。QPid JMS ConnectionFactory には同期パブリッシュ オプションがあり、基本的に各メッセージに対して ack が必要になるため、未解決のメッセージを送信しないようにできるかどうかを確認できます。

QPid JMS クライアントが最もパフォーマンスの高い AMQP 1.0 クライアントとして実装されているとは思いませんが、概念実証に近いため、新しいクライアントが作成されると変更される可能性があります。ここでのもう 1 つのボトルネックは、ActiveMQ が使用する Proton-J の現在の実装は、長い間強化されてきた OpenWire トランスポートと比較してパフォーマンスが低いため、そのライブラリが改善されるまでパフォーマンスが低下することです。Proton-J は常に進化しているため、時間の経過とともに改善されるはずです。

AMQP クライアントのみを使用して送受信している場合は、ActiveMQ で AMQP トランスポートを構成して raw トランスフォーマー オプションを使用できます。これにより、各メッセージの処理量が削減されますが、大幅な節約にはなりません。 

<transportConnector name="amqp" uri="amqp://localhost:5672?transport.transformer=raw"/>

最善の策は、QPid JMS クライアント コードを調べて、安定した永続メッセージを送信するように構成できるかどうかを確認することです。

この段階では、OpenWire は AMQP より ActiveMQ の方が常に高速になるため、AMQP を使用するやむを得ない理由がない限り、ネイティブの OpenWire クライアントに固執してください。ActiveMQ のトランク バージョン (v5.11-SNAPSHOT) を試すことができます。これは、AMQP 側でいくつかの追加作業が行われ、もう少し改善され、いくつかの改善が加えられた Proton-J の最新リリースが使用されます。そして、これは継続的な作業の領域になるため、時間の経過とともにパフォーマンスの全体像が改善されることが期待できます。

于 2014-07-16T02:05:31.587 に答える