Rendimiento muy bajo utilizando el puente central HornetQ

Question

Estamos intentando utilizar el mecanismo de almacenamiento y reenvío de HornetQ...sin embargo, reenviar mensajes desde una instancia independiente de HornetQ a otra usando el puente central es muy lento.No hemos podido aumentar la tasa de rendimiento por encima de 200 mensajes por segundo.

El hecho sorprendente es que si apuntamos el mismo cliente (que estaba publicando mensajes a la instancia de HornetQ de reenvío) directamente a la instancia de HornetQ de destino, comenzamos a observar una tasa de rendimiento de más de 1000 mensajes por segundo (este cliente está basado en JMS).Básicamente, esto significa que el puente central que se ha configurado entre la instancia de Forwarding HornetQ y la instancia de Destination HornetQ es problemático.

Las siguientes son las secciones relevantes para configurar el puente central en 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>

Las siguientes son las secciones relevantes para configurar el puente central en el Destino 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>

Todas las variables del sistema (CPU/Memoria/Disco IO/Red/etc.) están infrautilizadas y no hay errores en los registros.

Nota:Lo hemos probado tanto con NIO como con el IO antiguo/heredado.Esto se ha probado tanto con HornetQ-2.2.5-Final como con HornetQ-2.2.8-GA (2.2.8-GA se creó desde el código fuente)

¿Alguna idea de qué podría estar causando este problema y cuál podría ser la solución?

Otras observaciones:Parece que los mensajes que se envían a través del puente central son transaccionales...Entonces, ¿es posible agrupar estas transacciones por lotes y que la comunicación entre las dos instancias de HornetQ se produzca de forma asincrónica?

Answer 1

DE ACUERDO ..Lo descubrí por mí mismo.

Cuando Forwarding HornetQ crea un puente, utiliza internamente solo un hilo para enviar los mensajes a través del puente y abre solo una conexión con el Destino HornetQ.Como tal, no puede aprovechar múltiples procesadores y también está limitado por la red (latencia/ancho de banda/rtt) y no puede paralelizar de manera efectiva el envío de mensajes.Como tal, si tiene un alto rendimiento, comenzará a alcanzar un límite (en nuestro caso, alrededor de 200 mensajes por segundo).Puede aumentar esto modificando los parámetros del Conector y Aceptador de HornetQ (como los tamaños del búfer de envío y recepción de TCP) y la Configuración del puente (tamaño de la ventana de confirmación), pero eso solo puede llevarle un tiempo determinado (obtuvimos un rendimiento de hasta alrededor de 300 mensajes por segundo). ).

La solución: crear múltiples puentes entre el mismo par de instancias de Forwarding y Destination HornetQ (que involucran las mismas colas).Esto paraleliza efectivamente la transferencia de mensajes y, por tanto, aumenta el rendimiento.La creación de tres puentes casi triplicó el rendimiento a 870 mensajes por segundo.

Lo ideal es que JBoss haga que esta paralelización sea configurable en el puente central.

Answer 2

Creo que estabas usando 2.2.5 (en tu publicación no queda claro qué versión estabas usando), que tenía un error en los puentes que causaba el problema que estabas diciendo.

En alguna versión, el puente enviaba mensajes de forma sincrónica en lugar de contar con las confirmaciones asíncronas.

Eche un vistazo a cómo se comportaría en la última versión.