Проблема производительности Servicemix ActiveMQ - PullRequest
Новая
       30

Проблема производительности Servicemix ActiveMQ

1 голос
/ 06 апреля 2010

Я использую apache servicemix и apache activeMQ в своем продукте. Здесь, в случае HttpConnector, я обнаружил проблему с производительностью.

Если я увеличу количество общего запроса за раз, то по мере увеличения числа очередь обмена застревает на любом компоненте. После того как все запросы начнут обрабатываться, большая часть обмена будет зависать в конечном компоненте или в компоненте диспетчера *. Размер кучи контейнера становится очень большим, и через некоторое время он аварийно завершает работу и перезапускается.

Я также использовал транзакционный менеджер. имя потока также упоминается как jms.

нужно срочно какое-то решение.

Ответы [ 2 ]

0 голосов
/ 28 декабря 2010

Вы можете попробовать использовать KahaDB вместо "amqPersistenceAdapter". Мы увидели огромное увеличение пропускной способности, просто переключившись на это.

вот конфигурация, которую мы использовали (которая сильно зависит от вашего приложения, но убедитесь, что «enableJournalDiskSyncs» имеет значение false) 

    <persistenceAdapter>
        <kahaDB directory="../data/kaha"
            enableJournalDiskSyncs="false"
            indexWriteBatchSize="10000"
            indexCacheSize="1000" />
    </persistenceAdapter>
0 голосов
/ 20 апреля 2010

Если я увеличу общее количество запросов одновременно, то по мере увеличения числа очередь обмена будет зависать на любом из компонентов.

ActiveMQ имеет механизм, который останавливает написание сообщений производителем, он называется «управление потоком», кажется, что ваш производитель работает быстрее, чем потребитель (или потребитель не стабилен по своей скорости), поэтому сначала проверьте конфигурацию memoryLimit для вашего AMQ ( также определение его или возможной специальной очереди). Попробуйте увеличить его. 

<destinationPolicy>
  <policyMap>
    <policyEntries>

      <policyEntry topic="FOO.>" producerFlowControl="false" memoryLimit="1mb">
        <dispatchPolicy>
          <strictOrderDispatchPolicy/>
        </dispatchPolicy>
        <subscriptionRecoveryPolicy>
          <lastImageSubscriptionRecoveryPolicy/>
        </subscriptionRecoveryPolicy>
      </policyEntry>

    </policyEntries>
  </policyMap>

Кроме того, вы можете отключить эту остановку обработки входящих сообщений с помощью опции producerFlowControl="false". Таким образом, в случае использования всего буфера AMQ замедлится, и все сообщения будут сохранены на HD. Подробнее Управление потоком данных и Курсоры сообщений

Размер кучи контейнера достигает очень большого значения, и через некоторое время происходит сбой и автоматический перезапуск.

Но в любом случае, это просто способ настройки вашего приложения, это не решение, потому что всегда будет случай, когда некоторые ресурсы закончатся:)

Вы должны ограничить входящие запросы или уравновесить их, например. используя фунт

...