Performance degradation after upgrading to Microsoft.Azure.Cosmos.Table to access Azure table storage

Viewed 443

We upgraded to the next version of SDK to access our Azure Table storage.

We observed performance degradation of our application after that. We even created test applications with identical usage pattern to isolate it, and still see this performance hit.

We are using .NET Framework code, reading data from Azure table.

Old client: Microsoft.WindowsAzure.Storage - 9.3.2

New client: Microsoft.Azure.Cosmos.Table - 1.0.6

Here is one of the sample tests we tried to run:

public async Task ComparisionTest1()
{
    var partitionKey = CompanyId.ToString();

    {
        // Microsoft.Azure.Cosmos.Table
        var storageAccount = Microsoft.Azure.Cosmos.Table.CloudStorageAccount.Parse(ConnectionString);
        var tableClient = Microsoft.Azure.Cosmos.Table.CloudStorageAccountExtensions.CreateCloudTableClient(storageAccount);
        var tableRef = tableClient.GetTableReference("UserStatuses");
        var query = new Microsoft.Azure.Cosmos.Table.TableQuery<Microsoft.Azure.Cosmos.Table.TableEntity>()
                            .Where(Microsoft.Azure.Cosmos.Table.TableQuery.GenerateFilterCondition("PartitionKey", "eq", partitionKey));
        var result = new List<Microsoft.Azure.Cosmos.Table.TableEntity>(20000);

        var stopwatch = Stopwatch.StartNew();
        var tableQuerySegment = await tableRef.ExecuteQuerySegmentedAsync(query, null);
        result.AddRange(tableQuerySegment.Results);
        while (tableQuerySegment.ContinuationToken != null)
        {
            tableQuerySegment = await tableRef.ExecuteQuerySegmentedAsync(query, tableQuerySegment.ContinuationToken);
            result.AddRange(tableQuerySegment.Results);
        }

        stopwatch.Stop();
        Trace.WriteLine($"Cosmos table client. Elapsed: {stopwatch.Elapsed}");
    }

    {
        // Microsoft.WindowsAzure.Storage
        var storageAccount = Microsoft.WindowsAzure.Storage.CloudStorageAccount.Parse(ConnectionString);
        var tableClient = storageAccount.CreateCloudTableClient();
        var tableRef = tableClient.GetTableReference("UserStatuses");
        var query = new Microsoft.WindowsAzure.Storage.Table.TableQuery<Microsoft.WindowsAzure.Storage.Table.TableEntity>()
                            .Where(Microsoft.WindowsAzure.Storage.Table.TableQuery.GenerateFilterCondition("PartitionKey", "eq", partitionKey));
        var result = new List<Microsoft.WindowsAzure.Storage.Table.TableEntity>(20000);

        var stopwatch = Stopwatch.StartNew();
        var tableQuerySegment = await tableRef.ExecuteQuerySegmentedAsync(query, null);
        result.AddRange(tableQuerySegment.Results);
        while (tableQuerySegment.ContinuationToken != null)
        {
            tableQuerySegment = await tableRef.ExecuteQuerySegmentedAsync(query, tableQuerySegment.ContinuationToken);
            result.AddRange(tableQuerySegment.Results);
        }

        stopwatch.Stop();
        Trace.WriteLine($"Old table client. Elapsed: {stopwatch.Elapsed}");
    }
}

Anyone observed it, any thoughts about it?

2 Answers

I think your data are stored in the legacy Storage Table. Just in case, if this is CosmosDB Table backed, you may get better performance if you set TableClientConfiguration.UseRestExecutorForCosmosEndpoint to True.

If it's the legacy Storage Table store, CosmosDB Table sdk 1.0.6 is about 15% slower than Storage Table sdk 9.3.3. In addition, it has an extra second overhead upon the first CRUD operation. Higher query duration has been resolved in 1.0.7, which is on-par with Storage SDK. The initialization second is still required why using CosmosDB Table sdk 1.0.7, which should be acceptable.

We are planning to release 1.0.7 during the week of 4/13.

The performance issue will be resolved in Table SDK 1.0.7 as verified with large entity. On 1.0.6 the workaround is to disable Table sdk trace by adding diagnostics section in app.config if it's a .NET framework app. It will still be slower than Storage sdk, but much better than without the workaround depending on the usage.

Related