Molto Basso Throughput Utilizzando Il HornetQ Core Ponte

Question

Stiamo cercando di utilizzare il HornetQ meccanismo di archiviazione e inoltro...tuttavia l'inoltro dei messaggi da uno standalone HornetQ istanza all'altra, utilizzando il core ponte è molto lento.Non siamo stati in grado di aumentare la velocità di trasmissione superiori a 200 messaggi al secondo.

Il fatto sorprendente è che, se ci punto il client stesso (che è stata la pubblicazione di messaggi per l'inoltro HornetQ esempio) direttamente a destinazione HornetQ esempio, possiamo iniziare a osservare una velocità di trasferimento di oltre 1000 messaggi al secondo (questo client JMS base).Questo in pratica significa che il core ponte che è stato configurato tra l'Inoltro HornetQ istanza e la Destinazione HornetQ istanza è problematico.

Le seguenti sono le sezioni rilevanti per la configurazione del core ponte sul Inoltro 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>

Le seguenti sono le sezioni rilevanti per la configurazione del core ponte sulla Destinazione 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>

Tutte le variabili di sistema (CPU, Memoria e i / o su Disco/Rete/etc.) sono sottoutilizzati e non ci sono errori nei log.

Nota:Abbiamo provato sia con NIO, e l'eredità/vecchio IO.Questo è stato provato sia con HornetQ-2.2.5-Finale e HornetQ-2.2.8-GA (2.2.8-GA è stato costruito da fonte)

Qualsiasi idea di cosa potrebbe essere causato questo problema e che la risoluzione potrebbe essere?

Altre osservazioni:Sembra che i messaggi vengono inviati attraverso il nucleo del ponte sono transazionale...così è possibile batch di queste operazioni, e hanno la comunicazione tra i due HornetQ istanze accadere in modo asincrono?

Answer 1

OK ..Ho capito questo, per me.

Quando l'Inoltro HornetQ crea un ponte, internamente utilizza un solo thread per inviare i messaggi su un ponte e si apre solo una connessione a Destinazione HornetQ.Come tale, essa non è in grado di sfruttare più processori e anche limitato dalla rete (latenza / banda / rtt) e non è in grado di parallelizzare l'invio di messaggi.Come tale, se si dispone di un alta velocità di trasmissione, è iniziare a colpire con un tappo (nel nostro caso circa 200 messaggi al secondo).È possibile aumentare questo, modificando la HornetQ Connettore e Accettore di parametri (come il TCP inviare e ricevere le dimensioni del buffer) e le Impostazioni del Bridge (conferma la dimensione della finestra), ma che può solo prendere così a lungo (abbiamo ottenuto il throughput fino a circa 300 messaggi al secondo).

La soluzione di creare più ponti tra la stessa coppia di spedizione e di Destinazione HornetQ istanze (che coinvolgono lo stesso code).Questo effettivamente parallelizes il trasferimento di messaggi e di conseguenza aumenta la velocità di trasmissione.La creazione di tre ponti, ha quasi triplicato la velocità effettiva a 870 messaggi al secondo.

JBoss deve idealmente fare questo parallelizzazione configurabile nel core ponte.

Answer 2

Credo si utilizza 2.2.5 (non È chiaro dal tuo post che la versione in uso) che aveva un bug sui ponti causando il problema che si stavano dicendo.

In alcune versioni, il ponte è stato l'invio di messaggi in modo sincrono, invece di contare sul async conferme.

Date un'occhiata a come si comporterebbe l'ultima versione.