Сервисная шина Azure - определение количества активных подключений (тема / очередь)

Поскольку служебная шина Azure ограничивает максимальное количество одновременных подключений к очереди или теме до 100, есть ли метод, который мы можем использовать для запроса наших очередей / тем, чтобы определить, сколько существует одновременных подключений?

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

Вариант использования здесь - это процесс, ожидающий ответного сообщения, где ответ исходит от длительного процесса, а подписка использует фильтр корреляции для облегчения двусторонней связи между издателем и подписчиком. Таким образом, мы должны запустить BeginReceive (), чтобы ожидать ответа, и каждый такой издатель будет использовать соединение в течение своего времени ожидания. Система уже распределяет нагрузку по нескольким темам, но нам нужен способ заблаговременно определять, сколько тем создается, чтобы нас не слишком часто ограничивали, но в то же время не было лишних тем для этой цели.


person Pittsburgh DBA    schedule 18.09.2012    source источник


Ответы (1)


Я не верю, что в настоящее время возможно запросить количество слушателей. Я думаю, что объект подписчика также фигурирует в этом, поэтому теоретически, если у вас есть до 2000 подписчиков на тему, и если каждая из них допускает до 100 подключений, это много потенциальных подключений. Нам просто нужно иметь в виду, что подписчики взаимодействуют друг с другом (каждый получает копию всех сообщений), а получатели на подписчиках являются конкурентоспособными (только один получает это).

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

Но ... учитывая ваш сценарий, я бы сделал вывод, что время производительности, вероятно, не самый большой фактор (у вас уже есть длительные процессы). Так что введение задержки в пару секунд в рабочий процесс, скорее всего, не будет критичным. Если это так, я бы установил тайм-аут для вашего BeginRecieve на что-то довольно короткое (пара секунд) и имел бы задержку сна / ожидания между попытками. Это дает другим слушателям возможность также получать сообщения. Мы также можем рассмотреть подход, при котором мы пытаемся получить несколько сообщений, а затем назначить их другим процессам для обработки (в данном случае взаимодействие?).

Высыпает некоторые мысли.

person BrentDaCodeMonkey    schedule 18.09.2012
comment
Мне очень нравится ваша идея иметь некоторую задержку сна / ожидания между попытками BeginReceive для уменьшения количества одновременных подключений. Это было бы идеально в данном сценарии, поскольку большинство этих процессов занимают от 30 секунд до 5 минут. Мы могли бы захотеть рассмотреть что-то, где сон / ожидание увеличивается каждый раз до установленного предела. Логика может быть примерно такой: чем дольше мы ждали, тем выше вероятность того, что это более длительный процесс и т. Д. Это заставит самых продолжительных слушателей меньше слушать и больше спать. Мне это нравится! - person Pittsburgh DBA; 19.09.2012
comment
Это паттерн отступления, и это довольно распространенное явление. Если это работает для вашего сценария, я определенно рекомендую использовать. :) - person BrentDaCodeMonkey; 19.09.2012
comment
Вы знаете, приведет ли этот шаблон к дополнительным расходам? IIRC, Storage Queues взимает плату за чтение независимо от того, доставлено сообщение или нет. Напротив, кажется, что служебная шина взимает плату только за отправленные, доставленные или удаленные сообщения и т. Д. Будет ли за каждое новое соединение взиматься одна транзакция? - person Pittsburgh DBA; 19.09.2012