Azure Tables loadtest

Our Session data is saved in Azure Tables. It is identified with a GUID and grouped by Instruments. But we didn’t use PartitionKey or RowKey in our implementation.

The PartitionKey hands the ability to logicaly group data. The RowKey identifies the records within these groups. Togheter the PartitionKey and the RowKey form the unique identification.

But just by using the InstrumentId as PartitionKey and the SessionId as Rowkey no performance difference was achieved. We had to change the queries. The field PartitionKey is used in stead of the InstrumentId in where clauses. The same for the field RowKey and SessionId.

// no optimization, by using the Id field in the query
return Sessions.Where(entity => entity.Id.Equals(sessionId.ToString())).FirstOrDefault();

// correct usage of RowKey
return Sessions.Where(entity => entity.RowKey.Equals(sessionId.ToString())).FirstOrDefault();

Meassuring the create, read, update and delete of up to 200 users in a loadtest gave us the proof that using PartitionKey and RowKey did pay off. In the graphs below you can see the average time needed for reading a record by its Id. After optimization the RowKey became the Id.

About erictummers

Working in a DevOps team is the best thing that happened to me. I like challenges and sharing the solutions with others. On my blog I’ll mostly post about my work, but expect an occasional home project, productivity tip and tooling review.
This entry was posted in Development and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.