Azure Tables Performance Tuning

Feb 9, 2010 at 8:36 PM

I have just started the actual process of performance tuning my Azure code.  So where do you start?

Fortunately there is a resource that can help - Brad Calder (Azure Architect/Director).  In his Mix09 presentation Brad talks about the entire Azure storage model, specifically starting with slide 33 he talks about quering Azure tables.  (Bing: MIX09 Windows Azure Storage - Calder here ).

For those who want just the bullets -

  • Default .NET HTTP connections is set to 2
    -ServicePointManager.DefaultConnectionLimit = X;
  • Turn off 100-continue (saves one round trip)
    -ServicePointManager.Expect100Continue = false;
  • Turn tracking off for query results that are not going to be modified
    -MergeOption = MergeOption.NoTracking
  • To improve performance of ADO.NET de-serialization
    -Name the entity class the same as the table name, or
    -Use DataServiceContext.ResolveType to return the type of the entity

The component that I have described is designed to exploit the class/table naming relationship.  BUT if you want to have fewer Azure tables and fewer VS projects in your solution, I have a suggestion or two.

First note that YOU must either sacrifice some ADO.NET performance "potentially" or use the ResolveType as suggested above.  I haven't tried that as of yet.

Nevertheless here is what you do to "re-use" Azure tables using the component.

In the project created by the Visual Studio Azure Table Storage template there are five .cs files, three contain the word "Data" and the other two do not.  It is fairly obvious that the AzureTableInit.cs and IAzureSettings.cs are concerned with the configuration while the "Data" files are about the table content.

To have a project share a single Azure table you create additional copies of the "Data" files in the same project.  Naturally you need to rename the class names and the file themselves.  Further I suggest that you might make a couple other names more generic when used this way.  Look at the code snipet from the AzureTableInit.cs file:

/// <summary>
/// This is one and only Clients Table Name. Do not remove.
/// The public version is located in ProfileDataServiceContext.
/// </summary>
internal static string Clients;

// In production code UNcomment line and then set the literals to the desired values.
// Optionally, use the dynamic setting from the WebRole.cs
//internal const string AzureTableDataConnectionString = "DataConnectionString";

// If you want to hard code the table name, replace the empty string with a valid Azure table
// name. CAUTION! will override any other setting if it is not empty.
internal const string HardCodeTableName = "";

Notice the two named items above.  Here I have set the table name to the same name as my Project namespace. I also changed the "hard code table name" to a generic name.
Finally, if you want to optimize the naming then you must violate the "naming conventions" normally used by C# best practices.  If you document your reasons for the inconsistant naming then you could get optizimation from the ADO.NET without any other coding on your part.