Débit très bas à l'aide du pont de corne horneTQ

Question

Nous essayons d'utiliser le mécanisme HornetQ Store et Transférer ... cependant expédier des messages d'une instance autonome Hornetq à un autre à l'aide du pont de base est très lent. Nous n'avons pas pu augmenter le taux de débit supérieur à 200 messages par seconde.

Le fait surprenant est que si nous indiquons le même client (qui publiait des messages vers l'instance de Hornetq transfert) directement à l'instance de destination Hornetq, nous commençons à observer un taux de débit de plus de 1000 messages par seconde (ce client est basé sur JMS. ). Cela signifie fondamentalement que le pont central qui a été configuré entre l'instance Hornetq Transfert et l'instance de destination Hornetq est problématique.

Ce qui suit sont les sections correspondantes pour la configuration du pont de base sur le transfert 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>

Voici les sections correspondantes pour la configuration du pont de base sur la 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>

Toutes les variables système (CPU / mémoire / disque IO / Network / etc.) sont sous-utilisées et il n'y a pas d'erreur dans les journaux.

note : nous avons essayé avec Nio ainsi que l'héritage / Old Io. Cela a été essayé à la fois avec HornetQ-2.2.5-Final et HornetQ-2.2.8-GA (2,2,8-GA a été construit à partir de la source)

Une idée quant à ce qui pourrait causer cette question et quelle est la résolution?

Autres observations : On dirait que les messages sont envoyés via le pont de base sont transactionnels ... Ainsi est-il possible de lotcher ces transactions et que la communication entre les deux instances HornetQ se produisent de manière asynchrone?

Answer 1

OK .. Je l'ai compris pour moi-même.

Lorsque le transfert HornetQ crée un pont, il n'utilise qu'un seul thread pour envoyer les messages sur le pont et n'ouvre qu'une connexion à la destination Hornetq. En tant que tel, il n'est pas en mesure de tirer parti de plusieurs processeurs et est également limité par le réseau (latence / bande passante / RTT) et n'est pas capable de paralleraliser efficacement l'envoi de messages. En tant que tel, si vous avez un débit élevé, vous commencez à frapper une casquette (dans notre cas environ 200 messages par seconde). Vous pouvez augmenter cela en modifiant le connecteur HornetQ et les paramètres d'accepteur (comme les tailles de tampon d'envoi de TCP et de réception) et des paramètres de pont (taille de la fenêtre de confirmation) mais qui ne peut que vous prendre si longtemps (nous avons eu le débit jusqu'à environ 300 messages par seconde. ).

La solution - Créez plusieurs ponts entre la même paire d'instances de transporteur de transfert et de destination (impliquant les mêmes files d'attente). Cela parallement le transfert de messages et augmente ainsi le débit. Créer trois ponts a presque triplé le débit à 870 messages par seconde.

JBoss doit idéalement rendre cette parallélisation configurable dans le pont de base.

Answer 2

Je pense que vous utilisiez 2.2.5 (ce n'est pas clair de votre message, quelle version que vous utilisiez) qui avait un bug sur les ponts causant le problème que vous disiez.

à une autre version, le pont envoie des messages de manière synchrone au lieu de compter sur les confirmations ASYNC.

Regardez comment il se comporterait sur la dernière version.