Очень низкая пропускная способность при использовании основного моста HornetQ

Question

Мы пытаемся использовать механизм хранения и пересылки 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 / Memory / Disk IO / Network / и т. Д.) Используются недостаточно, и естьв журналах ошибок нет.

Примечание : мы пробовали как с NIO, так и со старым / старым IO.Это было опробовано как с HornetQ-2.2.5-Final, так и с HornetQ-2.2.8-GA (2.2.8-GA был построен из исходного кода)

Любая идея относительно того, что может вызывать эту проблему и чторазрешение может быть?

Другие наблюдения : Похоже, что сообщения, передаваемые через базовый мост, являются транзакционными ... поэтому возможно ли пакетировать эти транзакции и иметь связь междудва экземпляра HornetQ происходят асинхронно?

Answer 1

ОК .. Я понял это для себя.

Когда Forwarding HornetQ создает мост, он внутренне использует только один поток для отправки сообщений через мост и открывает только одно соединение с Destination HornetQ. Как таковой, он не способен использовать преимущества нескольких процессоров, а также ограничен сетью (задержка / пропускная способность / RTT) и не способен эффективно распараллеливать отправку сообщений. Таким образом, если у вас высокая пропускная способность, вы начинаете стремиться к пределу (в нашем случае около 200 сообщений в секунду). Вы можете увеличить это, изменив параметры HornetQ Connector и Acceptor (например, размеры буфера отправки и получения TCP) и Bridge Settings (размер окна подтверждения), но это может занять очень много времени (мы получили пропускную способность примерно до 300 сообщений в секунду). ).

Решение - создать несколько мостов между одной и той же парой экземпляров Forwarding и Destination HornetQ (включая одни и те же очереди). Это эффективно распараллеливает передачу сообщений и, таким образом, увеличивает пропускную способность. Создание трех мостов почти утроило пропускную способность до 870 сообщений в секунду.

В идеале JBoss необходимо настроить эту параллелизацию в базовом мосту.

Answer 2

Я полагаю, что вы использовали 2.2.5 (из вашего поста не ясно, какую версию вы использовали) с ошибкой на мостах, вызвавшей проблему, о которой вы говорили.

В некоторых версиях мост отправлял сообщения синхронно, а не рассчитывал на асинхронные подтверждения.

Посмотрите, как он будет себя вести в последней версии.