Throughput molto basso utilizzando HornetQ Core Bridge

Question

Stiamo tentando di utilizzare il meccanismo di archiviazione e inoltro di HornetQ ... tuttavia l'inoltro di messaggi da un'istanza HornetQ autonoma a un'altra utilizzando il bridge principale è molto lento. Non siamo stati in grado di aumentare la velocità di trasmissione oltre i 200 messaggi al secondo.

Il fatto sorprendente è che se puntiamo lo stesso client (che stava pubblicando messaggi all'istanza HornetQ di inoltro) direttamente nell'istanza HornetQ di destinazione, iniziamo a osservare una velocità di trasmissione di oltre 1000 messaggi al secondo (questo client è JMS basato). Ciò significa fondamentalmente che il bridge principale che è stato configurato tra l'istanza Forwarding HornetQ e l'istanza Destination HornetQ è problematico.

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

Le seguenti sono le sezioni per la configurazione del ponte principale sul HornetQ destinazione:

<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/I/O disco/rete/ecc.) Sono sottoutilizzate e non ci sono errori nei registri.

Nota: Abbiamo provato sia con NIO che con il vecchio/vecchio I/O. Questo è stato provato sia con HornetQ-2.2.5-Final che con HornetQ-2.2.8-GA (2.2.8-GA è stato costruito dalla sorgente)

Qualche idea su cosa potrebbe causare questo problema e quale sia la risoluzione potrebbe essere?

Altre osservazioni: Sembra che i messaggi vengono inviati attraverso il ponte principale sono transazionale ... così è possibile in batch tali operazioni e avere la comunicazione tra le due istanze HornetQ accadere in modo asincrono?

Answer 1

OK .. ho capito questo per me stesso.

Quando l'Hornet di inoltro Q crea un bridge, utilizza internamente solo un thread per l'invio dei messaggi sul bridge e apre una sola connessione al HornetQ di destinazione. Come tale, non è in grado di sfruttare i processori multipli ed è anche limitato dalla rete (latenza/larghezza di banda/rtt) e non è in grado di parallelizzare efficacemente l'invio di messaggi. Pertanto, se si dispone di un throughput elevato, si inizia a colpire un limite (nel nostro caso circa 200 messaggi al secondo). È possibile aumentare questo modificando i parametri di HornetQ Connector e Acceptor (come le dimensioni del buffer di invio e ricezione TCP) e Bridge (dimensioni della finestra di conferma), ma ciò può richiedere solo molto tempo (abbiamo ottenuto il throughput fino a circa 300 messaggi al secondo).

La soluzione: creare più bridge tra la stessa coppia di istanze HornetQ di inoltro e destinazione (che coinvolgono le stesse code). Questo parallelizza in modo efficace il trasferimento di messaggi e quindi aumenta il throughput. La creazione di tre bridge ha quasi triplicato il throughput a 870 messaggi al secondo.

JBoss deve idealmente rendere questa parallelizzazione configurabile nel core bridge.

Answer 2

Credo che stavate usando 2.2.5 (Non è chiaro dal vostro post quale versione stavate usando) che aveva un bug sui ponti che causava il problema che stavate dicendo.

In alcune versioni il bridge inviava messaggi in modo sincrono invece di contare sulle conferme asincrone.

Dai un'occhiata a come si comporterebbe nell'ultima versione.