Задержка, ожидающая сообщения очереди Azure

Question

Я запускаю облачную службу в режиме отладки в Visual Studio, и я вижу большую задержку с события нажатия кнопки на моем живом сайте и попадания в точку останова на моем сеансе отладки облачного сервиса. Это займет около 20-30 секунд от нажатия кнопки до появления сообщения о очереди. Это нормально? Это связано с тем, что он работает в режиме отладки, или это примерно соответствует тому, как оно будет выглядеть на производстве? Это мой первый проект облачных сервисов, поэтому я все еще участвую в поворотах. Я единственный человек, попавший в облачный сервис, поскольку он все еще находится в разработке.

EDIT для добавления кодовых вызовов.

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

CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient(); 

//Retrieve a reference to a queue. 
CloudQueue queue = queueClient.GetQueueReference("queue"); 

//Create the queue if it doesn't already exist. 
queue.CreateIfNotExists(); 

//Create a message and add it to the queue. 
CloudQueueMessage message = new CloudQueueMessage(filename); 

queue.AddMessage(message, timeToLive: TimeSpan.FromMinutes(1), initialVisibilityDelay: null); 

Этот вызов занимает около 30 секунд, чтобы забрать здесь в WorkerRole:

 // Retrieve a reference to a container. 
     CloudBlobContainer container = blobClient.GetContainerReference("mycontainer"); 
     CloudBlobContainer hmtlcontainer = blobClient.GetContainerReference("conthtml"); 

     // Create the container if it doesn't already exist. 
     container.CreateIfNotExists(); 
     hmtlcontainer.CreateIfNotExists(); 

     // Create the queue client 
     CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient(); 

     // Retrieve a reference to a queue 
     CloudQueue queue = queueClient.GetQueueReference("queue"); 

     try 
     { 
      // Look for a new queue message 
      CloudQueueMessage peekedMessage = queue.GetMessage(visibilityTimeout: TimeSpan.FromSeconds(3)); 

Answer 1

MikeWo's answer Правильно, что, чтобы быть уверенным, почему вы видите столько латентности, вам нужно выяснить, где эта латентность действительно исходит из вашего кода. Если вы публикуете конкретный звонок или звонки, которые медленны, мы можем, вероятно, предоставить более эффективные рекомендации. Как бы то ни было, мы в основном просто размышляем. Это, как говорится, я хотел бы добавить некоторые предположения, предполагая задержка связана с хранением Azure:

1. Это не объясняет все задержки, но проверить, где в мире вы фактически призывая. Если ваша учетная запись хранится в Азии, и вы находитесь в Калифорнии, вы увидите гораздо больше латентности, если ваш код работает в местоположении ближе к центру обработки данных.
2. Для сообщения в очереди, убедитесь, что ваш тайм-аут видимости низкий (или 0), когда вы помещаете сообщение. Если тайм-аут видимости вашего сообщения составляет 30 секунд, он не будет отображаться на 30 секунд.
3. Подтвердите, сколько вызовов памяти вы на самом деле делаете. Если вы создаете очередь, ставя сообщения, опросы ... и т. Д., Это займет гораздо больше, чем процитированные 10 мс для небольших сообщений. Если вы выясните, что медленно использует совет Майка, это поможет вам отлаживать дальше.

Answer 2

Нет, задержка не должна быть так долго вообще. Я определенно думаю, что это больше связано с удаленной отладкой. Существует много информации, которая идет между IDE и отлаженным процессом. При удаленной отладке я вижу, что это занимает некоторое время. Я обычно использую эмулятор для моей отладки, если не требуется абсолютно отладка из рабочей облачной среды.

Если бы вы были вами, я бы добавил телеметрию к вашему протоколу, чтобы увидеть, когда вы получили сообщения, сколько времени они прошли для обработки и т. Д. Затем, когда вы запускаете вне отладки, вы получите лучшее представление о фактической обработке. Также обратите внимание, что вы можете взглянуть на свойства сообщения очереди для InsertionTime и сравнить это с тем временем, когда процессор выбирает его, чтобы посмотреть, как долго он сидит в очереди.