2012-03-13 3 views
6

우리는 HornetQ 저장 및 전달 메커니즘을 사용하려고합니다 ... 그러나 코어 브리지를 사용하여 하나의 독립형 HornetQ 인스턴스에서 다른 하나의 HornetQ 인스턴스로 메시지를 전달하는 것은 매우 느립니다. 우리는 초당 200 개 이상의 메시지 처리 속도를 높일 수 없었습니다.HornetQ 코어 브리지를 사용하여 매우 낮은 처리량

놀라운 사실은 대상 HornetQ 인스턴스에서 동일한 클라이언트 (즉, 전달 HornetQ 인스턴스에 메시지 게시)를 지시하면 우리는 초당 1000 개 이상의 메시지 처리 속도를 관찰하기 시작합니다 (이 클라이언트는 JMS입니다. 기반). 이것은 기본적으로 전달 HornetQ 인스턴스와 대상 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> 

다음

<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에 핵심 다리를 구성하는 관련 부분입니다 : 다음

는 전달 HornetQ에 핵심 브리지를 구성하기위한 관련 부분입니다 모든 시스템 변수 (CPU/메모리/디스크 IO/네트워크/등)는 충분히 활용되지 않으며 로그에 오류가 없습니다.

참고 : 우리는 NIO와 레거시/구형 IO를 모두 시도했습니다. 이것은 HornetQ-2.2.5-Final과 HornetQ-2.2.8-GA (2.2.8-GA는 출처에서 만들어졌습니다)와 함께 시도되었습니다.

이 문제의 원인과 해결 방법 아마도?

다른 관찰 : 메시지가 코어 브릿지를 통해 전송되는 것처럼 보이는 것은 트랜잭션입니다 ... 이러한 트랜잭션을 일괄 처리하고 두 HornetQ 인스턴스 간의 통신을 비동기 적으로 수행 할 수 있습니까?

+0

이것은 버그 수정 –

답변

3

OK .. 나는 이것을 스스로 알아 냈다.

전달 HornetQ는 브리지를 만들 때 브리지를 통해 메시지를 보내는 데 하나의 스레드 만 내부적으로 사용하고 대상 HornetQ에는 하나의 연결 만 엽니 다. 따라서 다중 프로세서를 이용할 수없고 네트워크 (대기 시간/대역폭/RTT)에 의해 제한되며 메시지 전송을 효과적으로 병렬화 할 수 없습니다. 따라서 처리량이 높으면 캡을 치기 시작합니다 (이 경우 초당 약 200 개의 메시지). HornetQ 커넥터 및 수락 자 매개 변수 (TCP 보내기 및 받기 버퍼 크기와 같은)와 브리지 설정 (확인 창 ​​크기)을 조정하여이 값을 늘릴 수는 있지만 너무 길어질 수 있습니다 (초당 약 300 개의 메시지 처리량이 있습니다.).

해결 방법 - 동일한 대기열을 포함하는 동일한 쌍의 전달 및 대상 HornetQ 인스턴스간에 여러 브리지를 만듭니다. 이는 효과적으로 메시지 전송을 병렬화하여 처리량을 증가시킵니다. 세 개의 브리지를 만들면 처리량이 거의 세 배가되어 초 당 870 개의 메시지가 생성됩니다.

JBoss는 코어 브리지에서이 병렬 처리를 구성 할 수 있도록 이상적으로 설정해야합니다.

+0

어떤 시점에서 버그가있었습니다. 제 대답 좀보세요. –

1

당신이 말한 문제를 일으키는 교량에 버그가있는 2.2.5 (사용중인 버전이 게시물에서 분명하지 않음)를 사용하고 있다고 생각합니다.

일부 버전에서는 브리지가 비동기 확인을 계산하는 대신 동 기적으로 메시지를 보내고있었습니다.

최신 버전에서 어떻게 작동하는지 살펴보십시오.

관련 문제