0

I am running my cloud service in debug mode in Visual Studio and I'm seeing a large delay from the button click event on my live site and hitting the breakpoint in my debug session of the cloud service. It takes about 20-30 seconds from button click until the queue message is present. Is this normal? Is this due to running in debug mode, or does this roughly represent what it would look like in production? This is my first cloud service project, so I'm still learning the knobs to turn. I am the only person hitting the cloud service as this is still in development.

EDIT to add code calls.

Here are the calls I am making from the website. The queue message is just a filename, so the message payload is very small.

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);

This call takes around 30 seconds to be picked up here in the 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)); 
stamm528
  • 113
  • 2
  • 17
  • Actually, it isn't clear if you were doing this remote debug actually connected to the cloud service in Azure, or in your emulator. I wouldn't expect to see high latency if you are debugging "locally" against the emulator, but if you are remote debugging attached to a machine running Azure, then maybe. – MikeWo Oct 20 '15 at 17:56
  • Is there any other processing going on in your WorkerRole during the loop? There's not enough code here to see what the code might be doing that would lengthen the amount of time between the GetMessages calls. Also, if this is in a loop then the additional calls to CreateIfNotExists and creating the cloudqueue client could be the issue. – MikeWo Oct 26 '15 at 15:44

2 Answers2

1

No, the latency should not be that long at all. I would definitely think it has more to do with remote debugging. There is a lot of information that goes between the IDE and a debugged process. When remote debugging like that I can see it taking a while. I tend to use the emulator for my debugging unless absolutely necessary to debug from a running cloud environment.

That being said, if I were you I'd add some telemetry to your logging to see when you picked up messages, how long they took to process, etc. Then when you run outside of debug you'll get a better idea of the actual processing. Also note that you can take a look at the properties of the queue message for the InsertionTime and compare that to the time the processor picks it up to see how long it sat in the queue.

MikeWo
  • 10,887
  • 1
  • 38
  • 44
  • Are you saying to just write off to a log file the time stamp from incoming to outgoing calls within the cloud service worker role? – stamm528 Oct 20 '15 at 16:27
  • On the Azure site here: https://azure.microsoft.com/en-us/documentation/articles/service-bus-azure-and-service-bus-queues-compared-contrasted/ I see the following comment: **The latency of Azure Queues is 10 milliseconds on average when handling small messages (less than 10 KB) from a hosted service located in the same location (region) as the storage account.** – stamm528 Oct 20 '15 at 16:44
  • I'm suggesting adding logging to your system, or telemetry in major actions. Being able to determine messages/second, average processing time per message type, etc. is all very important for a highly scalable system. Check out http://social.technet.microsoft.com/wiki/contents/articles/18468.telemetry-application-instrumentation.aspx for more content on this. But for this one specific issue, yeah, you could write to a log file, a DB table, a Storage Table, etc. But definitely try without the remote debugging. – MikeWo Oct 20 '15 at 17:54
0

MikeWo's answer is correct that to be sure of why you're seeing so much latency you'd need to figure out where that latency is actually coming from in your code. If you post the particular call or calls that are slow we can probably provide better advice. As it is, we're largely just speculating. That being said, I wanted to add some speculations assuming the latency has to do with Azure storage:

  1. It would not explain all of the latency, but check where in the world you're actually calling to. If your storage account is in Asia and you're in California, you're going to see much more latency then if your code is running in a location closer to the data center.
  2. Specific to queue messages, check that your visibility timeout is low (or 0) when you're putting the message. If your message visibility timeout is 30 seconds, it won't actually show up on gets for 30 seconds.
  3. Confirm how many storage calls you're actually making. If you're creating the queue, putting messages, polling... etc, it's going to take a lot more than the quoted 10 ms for small messages. If you figure out which is slow using Mike's advice, that will help you debug further.
Community
  • 1
  • 1
Emily Gerner
  • 2,427
  • 16
  • 16
  • Emily, thank you for the response. The website and cloud service all running in North Central, so #1 isn't an issue. I added my code above to show what I'm doing for #2. The visibility timeout can only be between 1sec and 7days, not sure if we are talking the same if you say zero. For #3, have a look at my code and you will see there isn't much going on here. Thank you for any guidance you can provide. – stamm528 Oct 21 '15 at 01:54
  • Emily, I changed the creation of the connection and the setting up of the client and the createifnotexist to be done once and run the rest of the code in a while (true) loop. This allowed the time to drop from 30 seconds to around 9 seconds. Not great, but much better. – stamm528 Oct 27 '15 at 01:56