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

Question

Мы пытаемся использовать механизм хранения и пересылки данных HornetQ...однако пересылка сообщений от одного автономного экземпляра HornetQ к другому с использованием core bridge происходит очень медленно.Нам не удалось увеличить пропускную способность выше 200 сообщений в секунду.

Удивительный факт заключается в том, что если мы направим тот же клиент (который публиковал сообщения для пересылающего экземпляра HornetQ) непосредственно на конечный экземпляр HornetQ, мы начнем наблюдать пропускную способность более 1000 сообщений в секунду (этот клиент основан на JMS).По сути, это означает, что основной мост, который был настроен между Отправляющим экземпляром 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 / Memory / Disk IO / Network / etc.) Используются недостаточно, и в журналах нет ошибок.

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

Есть какие-нибудь идеи относительно того, что может быть причиной этой проблемы и каким может быть решение?

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

Answer 1

ОК..Я сам до этого додумался.

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

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

В идеале JBoss должен сделать это распараллеливание настраиваемым в core bridge.

Answer 2

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

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

Взгляните на то, как это будет вести себя в последней версии.