Установите время ожидания видимости на 7 дней, чтобы автоматически удалить очередь Azure?

Кажется, что новый лазурный SDK увеличивает время ожидания видимости до ‹ = 7 дней. Я знаю, что по умолчанию, когда я добавляю сообщение в лазурную очередь, время жизни составляет 7 дней. Когда я получаю сообщение и устанавливаю время видимости на 7 дней. Означает ли это, что мне не нужно удалять это сообщение, если я не забочусь о надежности сообщения? сообщение исчезнет спустя 7 дней.

Я хочу пойти по этому пути, потому что DeleteMessage очень медленный. Если я не удалю сообщение, не повлияет ли это на производительность GetMessage?


azure azure-storage azure-storage-queues
person balto    schedule 22.12.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Основываясь на документации для Get Messages, я считаю, что это, безусловно, возможно установить период VisibilityTimeout равным 7 дням, чтобы сообщения извлекались только один раз. Однако я вижу некоторые проблемы с этим подходом вместо того, чтобы просто удалить сообщение после завершения процесса:

  • Что происходит, когда вы получаете сообщение и начинаете его обрабатывать, а процесс почему-то терпит неудачу? Если вы установите время ожидания видимости равным 7 дням, то сообщение больше никогда не появится в очереди, и, следовательно, процесс, который он должен был выполнить, никогда не будет выполнен.
  • Несмотря на то, что сообщение скрыто, оно все еще находится в очереди, поэтому вы продолжаете нести плату за хранение этого сообщения. Несмотря на то, что стоимость тривиальна, но зачем хранить сообщение, если оно вам на самом деле не нужно.
  • Многие системы полагаются на свойство Approximate Messages Count очереди для проверки работоспособности процессов, выполняемых сообщениями в очереди. Обратите внимание, что даже если вы сделаете сообщение скрытым, оно все еще находится в очереди и, таким образом, будет включено в общее количество сообщений в очереди. Поэтому, если вы создаете систему, которая полагается на это для проверки работоспособности, вы всегда обнаружите, что ваша система неработоспособна, потому что вы никогда не удаляете сообщения.

Мне любопытно узнать, почему вы находите удаление сообщений очень медленным. По моему опыту это довольно быстро. Как вы отслеживаете удаление сообщений?

person Gaurav Mantri    schedule 22.12.2013
comment
Спасибо за ответ. ваши точки действительно действительны. У меня огромная очередь и я хочу получать сообщения как можно быстрее, например, 2000 в секунду. Исходный шаблон Get-Delete. После профилирования большую часть времени я находил на Delete. Вот почему я хочу использовать этот подход. - person balto; 23.12.2013
comment
Чтобы удалить сообщение, вам понадобятся две вещи: Message Id и Pop Receipt, которые вы получаете, когда Get сообщения. Одним из возможных решений было бы выполнить удаление через какой-либо фоновый процесс, чтобы не затронуть ваш основной процесс. - person Gaurav Mantri; 23.12.2013

arrow_upward
0
arrow_downward

Вместо того, чтобы решать проблему, я думаю, вам следует углубиться в понимание того, почему удаления выполняются медленно. Включили ли вы журналы и просмотрели значения e2elatency и serverlatency для всех ваших операций с очередями. В идеале вы не должны видеть большой разницы между ними для всех ваших операций с очередями. Если вы видите большую разницу, это означает, что на клиенте происходит что-то, что вам следует исследовать дальше.

Дополнительные сведения о ведении журнала см. в следующих статьях: http://blogs.msdn.com/b/windowsazurestorage/archive/tags/analytics+2d00+logging+_2600_amp_3b00_+metrics/ http://msdn.microsoft.com/en-us/library/azure/hh343262.aspx

Информацию о ведении журнала на стороне клиента также можно найти в этом сообщении: ведение журнала на стороне клиента, о котором вы можете узнать больше в этом сообщении в блоге. http://blogs.msdn.com/b/windowsazurestorage/archive/2013/09/07/announcing-storage-client-library-2-1-rtm.aspx

Пожалуйста, дайте мне знать, что вы найдете.

Джейсон

person Jason Hogg - MSFT    schedule 16.05.2014