Столкновение с проблемой тестирования кластера с ActiveMQ Artemis

У меня есть 2 экземпляра ActiveMQ Artemis, просто созданные с помощью команды /.artemis create artemis / server1 и

/.artemis create artemis / server2

Я использую linux ubantu.

вот broker.xml для server1:

  <acceptors>
     <!-- Acceptor for every supported protocol -->
     <acceptor name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300</acceptor>

  </acceptors>

  <connectors>
     <connector name="netty-connector">tcp://localhost:61616</connector>
     <!-- connector to the server1 -->
     <connector name="server1-connector">tcp://localhost:61617</connector>
  </connectors>

 <cluster-connections>
     <cluster-connection name="my-cluster">
        <connector-ref>netty-connector</connector-ref>
        <retry-interval>500</retry-interval>
        <use-duplicate-detection>true</use-duplicate-detection>
        <message-load-balancing>STRICT</message-load-balancing>
        <max-hops>1</max-hops>
        <static-connectors>
           <connector-ref>server1-connector</connector-ref>
        </static-connectors>
     </cluster-connection>
  </cluster-connections>

а вот broker.xml для server2:

     <!-- Acceptor for every supported protocol -->
   <acceptor name="artemis">tcp://0.0.0.0:61617?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300</acceptor>
  </acceptors>

  <connectors>
     <connector name="netty-connector">tcp://localhost:61617</connector>
     <!-- connector to the server0 -->
     <connector name="server0-connector">tcp://localhost:61616</connector>
  </connectors>

  <cluster-connections>
     <cluster-connection name="my-cluster">
        <connector-ref>netty-connector</connector-ref>
        <retry-interval>500</retry-interval>
        <use-duplicate-detection>true</use-duplicate-detection>
        <message-load-balancing>STRICT</message-load-balancing>
        <max-hops>1</max-hops>
        <static-connectors>
           <connector-ref>server0-connector</connector-ref>
        </static-connectors>
     </cluster-connection>
  </cluster-connections>

Также в server2 измените bootstrap.xml, измените порт веб-привязки

<web bind="http://localhost:8163" path="web">

Я тестирую его с помощью StaticClusteredQueueExample и этот пример рабочего файла.

Теперь я использую ActiveMQ Artemis JMeter Performance для своего кластера, я использую примеры тестирования JMeter, которые являются здесь

Теперь, когда я запускаю точка-точка test с Jmeter дает мне около 50% ошибок (совокупный отчет в Jmeter) у потребителя,

Но когда я использую только один узел (любой из server1 или server2) в системе ubantu, он работает нормально, частота ошибок 0% (Aggregate Report in Jmeter).

Не могли бы вы помочь, почему я получаю 50% ошибок (сводный отчет в Jmeter) при запуске нескольких экземпляров (узлов) с докером


activemq-artemis
person Bhushan Uniyal    schedule 30.11.2017    source источник
comment
Помощь действительно не может быть оказана, пока не станет ясно, в чем на самом деле заключаются ошибки. Кроме того, было бы полезно более четкое объяснение теста (например, JMeter запускается в одном из контейнеров Docker или где-то еще?). Наконец, правильно ли формируется кластер?   -  person Justin Bertram    schedule 30.11.2017
comment
@JustinBertram спасибо за ваш ответ, я обновил свой вопрос, также сталкиваюсь с той же проблемой без докера, поэтому обновленные данные проверяются на локальном компьютере (в Ubuntu).   -  person Bhushan Uniyal    schedule 01.12.2017

Ответы (1)


arrow_upward
1
arrow_downward

Проблема в том, что вы смешиваете один пример (то есть пример JMeter) с конфигурацией кластера (то есть из примера кластерного статического обнаружения), который действительно несовместим.

‹message-load-balancing> кластера СТРОГО, что означает, что сообщения будут сбалансированы по нагрузке в кластере независимо от присутствия потребителей. Кроме того, по умолчанию ‹redistribution-delay> является -1 означает, что сообщения, отправленные на другие узлы в кластере из-за типа балансировки нагрузки сообщений STRICT, останутся на этих узлах и не будут перераспределяться на основе потребительского спроса.

Пример JMeter был написан с учетом одного узла, поэтому он отправляет сообщения и потребляет сообщения только от одного узла, что означает, что он будет получать только половину сообщений, которые он отправляет, поскольку другая половина будет перенаправлена ​​на другой узел в кластер из-за конфигурации.

Если вы измените ‹message-load-balancing> на ON_DEMAND, вы не увидите никаких ошибок, так как все сообщения останутся на узле, на который они были специально отправлены, где также будет подключен потребитель.

person Justin Bertram    schedule 02.12.2017
comment
Привет, @Justin, может быть, я ошибаюсь, в StaticClusteredQueueExample соединение создается только с одним сервером ConnectionFactory cf0 = new ActiveMQConnectionFactory("tcp://localhost:61619");, но 4 потребителями получают данные со всех 4 серверов Artemis (с использованием циклического перебора). Теперь потребителем Jmeter является соединение с серверами TCP: // localhost: 61616, так почему же то же самое не происходит с потребителем Jmeter, почему кластер не возвращает данные для него ... - person Bhushan Uniyal; 02.12.2017
comment
StaticClusteredQueueExample использует ту же фабрику соединений для создания всех соединений, и именно поэтому соединения балансируются по нагрузке между узлами в кластере в циклическом режиме. Однако JMeter будет искать фабрику соединений в JNDI для каждого потока, что означает, что соединения не будут сбалансированы по нагрузке, поскольку на каждую фабрику соединений будет приходиться только 1 соединение. - person Justin Bertram; 02.12.2017
comment
Привет, Джастин, но балансировка нагрузки находится на стороне сервера.Если я говорю о балансировке нагрузки tomcat, то, если несколько запросов поступают из нескольких браузеров, тогда балансировщик нагрузки обрабатывает каждый запрос и распределяет все эти запросы (циклический режим) на нескольких узлах и возвращает ответ браузеру, но здесь половина запросов потребителя успешна, а 50% - нет. - person Bhushan Uniyal; 04.12.2017
comment
Балансировка нагрузки происходит на 2 уровнях. Есть балансировка нагрузки сообщений, которая выполняется брокером на основе ‹message-load-balancing›. Затем идет балансировка нагрузки соединения, которую выполняет клиент. Насколько я могу судить, в случае примера JMeter балансировки нагрузки соединения не происходит. Другими словами, все соединения концентрируются на одном узле кластера. Однако в то же время происходит балансировка нагрузки сообщений, поскольку сообщения распределяются между узлами в циклическом режиме, что приводит к голоду половины потребителей и вызывает ошибки. - person Justin Bertram; 04.12.2017