gpt4 book ai didi

messaging - 使用 HornetQ Core Bridge 的吞吐量非常低

转载 作者:行者123 更新时间:2023-12-04 15:25:42 25 4
gpt4 key购买 nike

我们正在尝试使用 HornetQ 存储和转发机制……但是使用核心桥将消息从一个独立的 HornetQ 实例转发到另一个实例非常慢。我们未能将吞吐率提高到每秒 200 条消息以上。

令人惊讶的事实是,如果我们将同一个客户端(即向转发的 HornetQ 实例发布消息)直接指向目标 HornetQ 实例,我们开始观察到每秒超过 1000 条消息的吞吐率(这个客户端是基于 JMS 的)。这基本上意味着在 Forwarding HornetQ 实例和 Destination HornetQ 实例之间配置的核心网桥有问题。

以下是在Forwarding 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>

以下是在Destination 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/网络等)都没有得到充分利用,并且日志中没有错误。

备注 :我们已经尝试过 NIO 以及遗留/旧 IO。这已经在 HornetQ-2.2.5-Final 和 HornetQ-2.2.8-GA 中尝试过(2.2.8-GA 是从源代码构建的)

关于可能导致此问题的原因以及可能的解决方案有什么想法吗?

其他观察 :看起来通过核心网桥发送的消息是事务性的......那么是否可以批处理这些事务并使两个 HornetQ 实例之间的通信异步发生?

最佳答案

好吧..我自己想通了。

当 Forwarding HornetQ 创建一个网桥时,它在内部只使用一个线程通过网桥发送消息,并且只打开一个到 Destination HornetQ 的连接。因此,它无法利用多个处理器的优势,并且还受到网络(延迟/带宽/rtt)的限制,并且无法有效地并行发送消息。因此,如果您的吞吐量很高,就会开始达到上限(在我们的例子中大约为每秒 200 条消息)。您可以通过调整 HornetQ 连接器和接受器参数(例如 TCP 发送和接收缓冲区大小)和桥接设置(确认窗口大小)来增加这一点,但这只会花费您很长时间(我们的吞吐量高达每秒 300 条消息)。

解决方案 - 在同一对 Forwarding 和 Destination HornetQ 实例之间创建多个网桥(涉及相同的队列)。这有效地并行化了消息的传输,从而增加了吞吐量。创建三个网桥几乎使吞吐量增加了两倍,达到每秒 870 条消息。

JBoss 需要在核心桥中理想地使这种并行化可配置。

关于messaging - 使用 HornetQ Core Bridge 的吞吐量非常低,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9685235/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com