Hornetq Core Bridgeを使用した非常に低いスループット
-
13-12-2019 - |
質問
私たちはHornetq StoreとForwardメカニズムを使用しようとしています...しかし、1つのスタンドアロンのHornetqインスタンスから別のスタンドアロンのメッセージの転送メッセージは非常に遅いです。毎秒200メッセージを超えるスループット率を上げることができませんでした。
驚くべき事実は、宛先HornetQインスタンスで直接同じクライアント(転送HornetQインスタンスにメッセージを発行していた)を指す場合、毎秒1000以上のメッセージのスループット率を観察します(このクライアントはJMSベースです。 )。これは基本的に、Forwarding HornetQインスタンスと宛先HornetQインスタンスの間に設定されているコアブリッジが問題があることを意味します。
フォワーディングHornetqのコアブリッジを設定するための関連セクションは、
です。<connectors>
<connector name="netty-bridge">
<factory-class>org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</factory-class>
<param key="host" value="destination.xxx.com"/>
<param key="port" value="5445"/>
<param key="batch-delay" value="50"/>
<param key="tcp-send-buffer-size" value="1048576"/>
<param key="tcp-receive-buffer-size" value="1048576"/>
<param key="use-nio" value="true"/>
</connector>
</connectors>
<address-settings>
<address-setting match="jms.queue.Record">
<dead-letter-address>jms.queue.RecordDLQ</dead-letter-address>
<max-size-bytes>262144000</max-size-bytes>
<page-size-bytes>10485760</page-size-bytes>
<address-full-policy>PAGE</address-full-policy>
</address-setting>
</address-settings>
<queues>
<queue name="jms.queue.Record">
<address>jms.queue.Record</address>
</queue>
</queues>
<bridges>
<bridge name="core-bridge">
<queue-name>jms.queue.Record</queue-name>
<forwarding-address>jms.queue.Record</forwarding-address>
<retry-interval>1000</retry-interval>
<retry-interval-multiplier>1.0</retry-interval-multiplier>
<reconnect-attempts>-1</reconnect-attempts>
<confirmation-window-size>10485760</confirmation-window-size>
<static-connectors>
<connector-ref>netty-bridge</connector-ref>
</static-connectors>
</bridge>
</bridges>
.
宛先Hornetq:
のコアブリッジを設定するための関連セクションは次のとおりです。<acceptors>
<acceptor name="netty">
<factory-class>org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory</factory-class>
<param key="host" value="${hornetq.remoting.netty.host:192.168.2.xxx}"/>
<param key="port" value="${hornetq.remoting.netty.port:xxxx}"/>
<param key="tcp-send-buffer-size" value="1048576"/>
<param key="tcp-receive-buffer-size" value="1048576"/>
<param key="use-nio" value="true"/>
<param key="batch-delay" value="50"/>
<param key="use-nio" value="true"/>
</acceptor>
<acceptors>
<address-settings>
<address-setting match="jms.queue.Record">
<dead-letter-address>jms.queue.RecordDLQ</dead-letter-address>
<max-size-bytes>262144000</max-size-bytes>
<page-size-bytes>10485760</page-size-bytes>
<address-full-policy>PAGE</address-full-policy>
</address-setting>
</address-settings>
<queues>
<queue name="jms.queue.Record">
<address>jms.queue.Record</address>
</queue>
</queues>
.
すべてのシステム変数(CPU /メモリ/ディスクIO /ネットワーク/ etcなど)はusより低くなり、ログにエラーはありません。
注:NIOとレガシー/古いIOの両方で試してみました。これは、Hornetq-2.2.5-FinalおよびHornetq-2.2.8-Ga(2.2.8-Gaがソースから造られた)
で試行されました。この問題を引き起こす可能性があるものと解像度が何であるかについての考え方は?
その他の観測:コアブリッジを介して送信されているメッセージがトランザクションのようになるように見えます...これらのトランザクションをバッチして、2つのHornetQインスタンス間の通信が非同期的に発生する可能性がありますか?
解決
OK ..私はこれを自分のために出した。
転送HornetQがブリッジを作成するとき、内部的にはブリッジを介してメッセージを送信するために1つのスレッドのみを使用し、宛先Hornetqへの接続は1つだけ開きます。このように、それは複数のプロセッサを利用することはできず、ネットワーク(待ち時間/帯域幅/ RTT)によっても制限され、メッセージの送信を効果的に並列化することができない。そのように、あなたが高いスループットを持っているならば、あなたはキャップを押し始める(私たちの場合は毎秒200メッセージの中で)。これを増やすことができます(TCP SendおよびReceive Buffer Sizesなど)とブリッジ設定(確認ウィンドウサイズ)を微調整することで、長い間にのみアクセスできます(私たちは毎秒約300メッセージまでのスループットを得ました。 )
解決策 - 同じペアの転送と宛先のHornetQインスタンス(同じキューを含む)の間に複数のブリッジを作成します。これにより、メッセージの転送が効果的に並列化され、したがってスループットが向上する。 3つのブリッジを作成すると、スループットを1秒あたり870メッセージにほぼ3倍にしました。
JBossは、理想的にはコアブリッジで設定可能なこの並列化を行う必要があります。
他のヒント
あなたが2.2.5を使っていたと思います(あなたが使っているバージョンからはっきりしていない)あなたが言っていた問題を引き起こしていた橋の上にバグを持っていました。
一部のバージョンでは、Bridgeは非同期確認をカウントするのではなく同期的にメッセージを送信していました。
最新バージョンでどのように行動するかを見てください。