2014-10-12 5 views
1

У меня есть приложение на основе PHP, которое использует Azure Queues. У моего приложения есть один cron, который работает на моем веб-сервере каждые 20 минут, и он добавляет до 2000 сообщений в хранилище очереди Azure. Он использовал, чтобы помещать эти сообщения в одну очередь, но теперь я использую две разные очереди, поочередно вставляя сообщение в каждый из них. Существует также период сна одной десятой секунды после того, как каждое сообщение добавляется в очередь, чтобы избежать дросселирования.Бесполезное поведение очереди Azure

У меня есть около 40 виртуальных машин на Azure, которые читаются из этой очереди, обрабатывают каждое сообщение, а затем обновляют базу данных, если какое-либо из этих сообщений вызывает определенное событие. Это происходит один раз в 100 сообщений.

Эти виртуальные машины имеют один скрипт PHP, который имеет максимальное время работы 900 секунд (set_time_limit (900)), и они запускаются как задания cron каждые 15 минут (900 секунд).

Проблема в том, что каждые полчаса (иногда каждый час) виртуальные машины не смогут ничего читать из очереди в течение нескольких минут. Сообщение будет пустым.

Это код, который я использую

$listMessagesResult = $queueRestProxy->listMessages($queue_name); 
$messages = $listMessagesResult->getQueueMessages(); 

Результат просто пустое сообщение. У меня есть следующий код для отслеживания ошибки

if (empty($messages)) { 
     error_log(print_r($messages, TRUE)); 
    } 

Он печатает и пуст массив. Именно это в моей журнал ошибок

Array\n(\n)\n 

Поскольку код работает большую часть времени, я не могу видеть, что это вопрос. Вот как я знаю, что это происходит регулярно http://i.imgur.com/RE9XtVS.png

Ось Y - количество сообщений. Ось X - это время. Количество сообщений принимается каждую минуту.

Плоская кривая после каждого альтернативного запуска сценария, который добавляет сообщение, показывает проблему. Если в коде возникла проблема, поведение не будет столь неустойчивым. Я не могу сказать, что не так, или где проблема может быть. Код довольно прямолинейный, и он работает большую часть времени, кроме тех 5-10 минут отсутствия активности.

Буду признателен за любую помощь по этому вопросу. Спасибо.

+2

Одна вещь, которую я бы рекомендовал, - включить учетную запись Storage Analytics в службе очереди и посмотреть, не происходит ли что-то фанки на уровне хранилища. После того, как аналитика хранилища включена, вы можете увидеть данные в контейнере blob '$ logs'. –

ответ

0

С помощью Gaurav's help Я смог прибить его. Я установил, что начальный тайм-аут видимости составляет 10 минут, и именно это заставило сообщения не отображаться в течение нескольких минут после их добавления в очередь. Я смутил конфигурацию «setVisibilityTimeoutInSeconds» со временем, когда сообщение снова появляется в очереди, если оно явно не удалено.