Azure Queue Storage Proper Call Pattern in 2015?

3
votes

What is the proper call/code pattern to write to Azure Queue Storage in a performant way?

Right now, the pseudo-code is

Create static class with StorageCredentials and CloudStorage account properies. At application startup, read values from config file into {get;}-only properties.

Create class with an async Task method with input parameter of my application message type. The method serializes the type, creates new CloudQueueMessage, new CloudQueueClient, new CloudQueue reference. Where configuration information is needed, it is read from the static class. My code then:

await Task.Run( ()=> theref.AddMessage(themessage).

It looks to me as if I have some redundancy in the code, and am not sure if/how connections might be pooled to the queue, and also if I require retry logic as I would with database (SQL Server etc) connectivity.

I am trying to understand which queue accessing steps can be reduced or optimized in any way.

All ideas appreciated.

Using .NET 4.5.2, C#. Code is executing in a Cloud Service (Worker Role).

Thanks.

2
azureazure-storage-blobsazure-storage-queuesretrypolicy

2 Answers

5
votes
  • Azure Storage Client Library already retries for you by default in case of service/network errors. It will retry up to 3 times per operation.
  • You can change your call to await theref.AddMessageAsync(themessage) instead of blocking on the synchronous AddMessage call on a separate thread.
  • As of the latest library, you can reuse the CloudQueueClient object to get a new reference to CloudQueue.
  • As long as you are calling AddMessageAsync sequentially, the same connection will be reused whenever possible. If you call it concurrently, more connections will be created, up to ServicePointManager.DefaultConnectionLimit connections. So, if you would like concurrent access to the queue, you might want to increase this number.
  • Disabling Nagle algorithm through ServicePointManager.UseNagleAlgorithm is also recommended given the size of queue messages.
2
votes

I would cache your CloudQueue reference and re-use it. Each time you add a message to the queue, this class constructs a REST call using HttpClient. Since your credentials and storage/queue Uri are already known this could save a few cycles.

Also, using AddMessageAsync instead of AddMessage is recommended.

As a reference, you can see the implementation in the storage client libraries here.