Slow Azure Table Search and Insert Operations on small tables

Question

I am trying to benchmark search/read & insert queries on an ATS which is small size(500 entities). Average insert time is 400ms and average search + retrieve time is 190ms.

When inserting, I am querying on the partition key and the condition itself is only composed of one predicate : [PartitionKey] eq <value> (no more ands/ors). Also, I am returning only 1 property.

What could be the reason for such results?

Search code:

TableQuery<DynamicTableEntity> projectionQuery = new TableQuery<DynamicTableEntity>().Select(new string[] { "State" });
        projectionQuery.Where(TableQuery.GenerateFilterCondition("PartitionKey", QueryComparisons.Equal, "" + msg.PartitionKey));
        // Define an entity resolver to work with the entity after retrieval.
        EntityResolver<bool?> resolver = (pk, rk, ts, props, etag) => props.ContainsKey("State") ? (props["State"].BooleanValue) : null;
        Stopwatch sw = new Stopwatch();
        sw.Start();
        List<bool?> sList = table.ExecuteQuery(projectionQuery, resolver, null, null).ToList();
        sw.Stop();

Insert Code:

CloudTable table = tableClient.GetTableReference("Messages");
        TableOperation insertOperation = TableOperation.Insert(msg);
        Stopwatch sw = new Stopwatch();
        // Execute the insert operation.
        sw.Start();
        table.Execute(insertOperation);
        sw.Stop();

Answer 1

You can refer to this post for possible performance issues: Microsoft Azure Storage Performance and Scalability Checklist.

The reason why you can only get one property is you're using EntityResolver, please try to remove that. Refer to Windows Azure Storage Client Library 2.0 Tables Deep Dive for the usage of EntityResolver - when you should use it and how to use it correctly.

Answer 2

From the SLA Document:

Storage

We guarantee that at least 99.99% of the time, we will successfully process requests to read data from Read Access-Geo Redundant Storage (RA-GRS) Accounts, provided that failed attempts to read data from the primary region are retried on the secondary region.

• We guarantee that at least 99.9% of the time, we will successfully process requests to read data from Locally Redundant Storage (LRS), Zone Redundant Storage (ZRS), and Geo Redundant Storage (GRS) Accounts.

• We guarantee that at least 99.9% of the time, we will successfully process requests to write data to Locally Redundant Storage (LRS), Zone Redundant Storage (ZRS), and Geo Redundant Storage (GRS) Accounts and Read Access-Geo Redundant Storage (RA-GRS) Accounts.

And also from there refereed document:

Table Query / List Operations
Maximum Processing Time: Ten (10) seconds (to complete processing or return a continuation)

There is no commitment for fast / low response time. Nor are there any commitments on being faster with smaller tables.