Почему мой Oracle AQ такой медленный с многопользовательской очередью - PullRequest
Новая
       43

Почему мой Oracle AQ такой медленный с многопользовательской очередью

2 голосов
/ 27 ноября 2010

новичок в Oracle AQ, но, похоже, это действительно должно упростить проект, над которым я работаю.

Я хочу создать очередь с несколькими постоянными подписчиками, но я обнаружил в ходе тестирования, что все замедляется, когда слушают 2 подписчика.

Когда слушает один подписчик, все быстро. Я создаю новые сообщения в очереди, и почти мгновенно они потребляются слушателем.

Затем я добавляю другого слушателя с другого сервера. Мгновенно Oracle замедляется. Создание сообщения в очереди занимает более 60 секунд. Сообщение не будет использовано до тех пор, пока через несколько минут.

Мне интересно, есть ли намного больше накладных расходов, когда очередь многопользовательская? Это накладные расходы только при запуске сервера? Или он всегда будет там?

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

Возможно, я сделал что-то не так в конфигурации моего слушателя?

Вот так я настроил свою таблицу очередей: 

EXEC dbms_aqadm.create_queue_table(queue_table=>'MY_QUEUE_TABLE',
     queue_payload_type=>'sys.aq$_jms_text_message',
     multiple_consumers=>TRUE);

А это моя конфигурация: 

<jms:listener-container 
        connection-factory="AQjmsFactory"
        container-type="default"
        destination-type="durableTopic"
        client-id="MY-ADAPTER" 
        acknowledge="transacted">
    <jms:listener destination="MYA_INFO_QUEUE" ref="personUpdateListener" subscription="MYADAPTERJ"/>
    <jms:listener destination="MYB_INFO_QUEUE" ref="courseUpdateListener" subscription="MYADAPTERJ"/>
</jms:listener-container>

1 Ответ

0 голосов
/ 28 ноября 2010

Это не столько «накладные расходы», сколько то, как модель работает с несколькими подписчиками. В обмене сообщениями есть определенное время «раскрутки» и «раскрутки». Тем не менее, база данных все еще относительно простаивает во время этих задержек. Вы не должны видеть значительного потребления CPU / Memory / IO во время ожидания начала обработки.

Если я понимаю, как все работает, есть фоновые задания, которые обрабатывают сообщения AQ, которые запускаются через определенные интервалы. Когда работа не выполняется, вы не записываете циклы, но ничего не происходит. Это все равно, что сказать, что ваш Ferrari работает медленно, когда двигатель не работает или когда вы сидите на красных огнях.

Чтобы проверить производительность , вам, вероятно, не следует беспокоиться об этих простоях, а не о том, что в очереди много сообщений для обработки. То есть когда Ferrari находится на открытой дороге!

...