Создает ли клиент Azure .OnMessage оплачиваемый запрос для пустых очередей?

Вы можете подписаться на асинхронные обновления из тем и очередей Azure, используя вызов SubscriptionClient/QueueClient .OnMessage, который предположительно создаст отдельный поток, опрашивающий тему/очередь с параметрами по умолчанию и вызывающий определенный обратный вызов, если он что-либо получает.

На веб-сайте Azure говорится, что получение сообщения является оплачиваемым действием, и это понятно. Однако недостаточно ясно, считается ли каждый из этих запросов на опрос подлежащим оплате, даже если они ничего не возвращают, т. е. в рассматриваемой очереди нет ожидающих сообщений.


azure azureservicebus azure-servicebus-queues servicebus
person Grozz    schedule 10.02.2014    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Согласно Часто задаваемым вопросам о ценах на Azure Service Bus, ответ на ваш вопрос да

Как правило, операции управления и «управляющие сообщения», такие как завершение и отсрочка, не считаются оплачиваемыми сообщениями. Есть два исключения:

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

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

Учитывая, что цена составляет 0,01 доллара за 10 000 сообщений, я не думаю, что вам следует слишком беспокоиться об этом.

person Tommy    schedule 10.02.2014
comment
Спасибо за проверку, просто кажется нелогичным предоставлять удобный механизм опроса, при котором пользователю выставляется счет за каждый запрос, частота которого устанавливается где-то в настройках по умолчанию предоставленного механизма. - person Grozz; 11.02.2014
comment
@Grozz - я не могу найти подробности, но я считаю, что OnMessage использует длительный опрос, то есть он запускается, запрашивает очередь для сообщения. Если есть, сразу возвращает. В противном случае он держит соединение открытым, пока может ожидать сообщения. Если ваша очередь используется мало, вы можете уменьшить ListenerCount до 1 или 2, чтобы свести к минимуму количество потоков, выдающих вызовы. Кроме того, если ваши сообщения не зависят от времени, вам может быть лучше использовать цикл while (true) с таймером, который постепенно отступает, если сообщения не были получены в течение определенного периода времени. - person Tommy; 11.02.2014
comment
@Grozz - вторая часть, вероятно, не слишком ясна, но мне не хватило места для комментариев. Есть примеры использования старого метода прослушивания очереди, который не зависит от обработчиков .OnMessage(). - person Tommy; 11.02.2014
comment
@Tommy, если он использует длительный опрос и отправку сервера, тогда все должно быть в порядке, у меня сложилось впечатление, что он просто опрашивает с помощью таймера под капотом. Спасибо, мне, вероятно, следует проверить количество запросов, чтобы действительно знать, что происходит. - person Grozz; 11.02.2014
comment
@Grozz Вы пробовали это? Каковы были ваши выводы? - person Lonefish; 18.11.2016