CODEWITHSUNDEEP
.netmultithreadingazureasynchronousazure-table-storage
Alex Rice
Alex Rice

Reputation: 173

azure tables API- should I use ExecuteAsync

I am pretty new to async C# coding, and for Azure tables there are sync + async calls to choose from. Supposing 1) I have to Get an entity in my method and 2) the thread doesn't have anything else it can do in the meantime, is there any reason at all to use the async version of code below? Will it add throughput to my multithreaded app, by freeing up the thread to work on different things. Not sure how deeply the synchronous call "blocks" things. I know it can take over 300ms sometimes to get a response from azure tables.

For context, I am coding for a Photon Socket Server implementation- it uses a thread pool and Fibers. I am implementing an interface like this (has no async events) protected override void OnOperationRequest(OperationRequest o, SendParameters p) I can do, however use async calls in Photon like this: requestFiber.Enqueue( () => DoStuff; );

/* synchronous version of code fragment */

entity = tableRetryPolicy.ExecuteAction( () => {
  var result = table.Execute (retrieveOp);
  if( result.HttpStatusCode == 404 ) 
    return null;
  App.CheckHttpStatusCode ("Get (Table) Retrieve", result, 200);
  return (T) result.Result;
});

/* async version of code fragment */
var task = tableRetryPolicy.ExecuteAsync( () => 
  table.ExecuteAsync (retrieveOp).ContinueWith( t =>
    {
      if (t.Exception != null)
      {
        // non-transient exception occurred or retry limit reached
        App.log.Error("Get (Table) failed all retries: entityId: " + entityId);
      }
      else
      {
        if( t.Result.HttpStatusCode == 404 )
          return;
        App.CheckHttpStatusCode ("Get (Table) Retrieve", t.Result, 200);
        entity = (T) t.Result.Result;
      }
    }
  )); 
task.Wait(); 
// ^  dont have anything else we can do with this execution path, except wait!

Upvotes: 0

Views: 1375

Answers (1)

Joe Giardino
Joe Giardino

Reputation: 364

This is more of a general .Net threading question. The storage apis exposed are truly synchronous and asynchronous, meaning a Sync method will block the calling thread and do all work on that thread, whereas the Async one will not block and make use of IO completion ports / calblacks. The Async storage apis also allow for pre-emptive cancellation, and pre-emptive timeouts which can help if you have tight performance requirements (See the request options timeout properties).

The biggest thing to consider is how many threads will your application need to consume. Regardless of what implementation / stack your using 1 thread per request will only scale to at max a few thousand concurrent requests as you will spend more time / memory swapping threads. (This also isn't great for the cache). Opinions regarding threading vary significantly, however in general for truly performant / high scale applications a implementation that uses few threads (roughly the number of logical processors twice that) and asynchronous requests will scale much higher and more linear than one with many threads & a synchronous implementation.

Upvotes: 1

Related Questions