Check out Glassboard — it’s free for iPhone, Android, and on the web for private group sharing. We wrote it.

Tech

Profiling Azure Storage with Fiddler part 2: Load First, Ask Later

In a previous post I talked about profiling your Windows Azure Storage using the Fiddler HTTP proxy. When I started profiling Glassboard with Fiddler, I saw a lot of traces like the one below.

Bad Query Example

Notice how the two highlighted HTTP requests are virtually identical. The only difference is that the first one has the query string argument $top=1 applied to it, so it will only retrieve the first result. In this case I want all the results back, so that first request is a complete waste. What’s going on? Here’s the code:

var query = (from row in base.Rows
    where row.PartitionKey == statusId
    select row).AsTableServiceQuery();

if (query.FirstOrDefault() == null) //BAD IDEA
{
    return new List<CommentInfo>(0);
}
else
{
    return query.ToList().ConvertAll(r => r.ToBoardStatusCommentInfo());
}

The query.FirstOrDefault() method call is the source of our problem. It causes that first HTTP request, and if it returns a value then the later query.ToList() method causes the second HTTP request. If you have set the DataServiceContext.IgnoreResourceNotFoundException to true you can eliminate the problem by loading the results without first checking if there are any results, like so:

var query = (from row in base.Rows
    where row.PartitionKey == statusId
    select row).AsTableServiceQuery().Take(max);

return query.ToList().ConvertAll(r => r.ToBoardStatusCommentInfo());

That simple change was enough to cut our storage traffic in half, which sped up the app considerably. Not only that, remember that each call to Azure Storage costs you money, so this is also a cost savings! If you’re a startup, that’s money staying in your pocket. If you work for a bigger company, put that savings on your quarterly review and ask for a raise!

Profiling Azure Storage with Fiddler

Fiddler Web Debugger is a tool well known by web developers on the Windows platform. If you need to see what your website is really doing, it’s absolutely invaluable. But if you’re storing data in Windows Azure Storage (Blobs, Queues or Tables) it gains a new use as a “database” debugging and profiling tool.

The easiest way to interact with Azure Storage is via the Microsoft-provided C# libraries. These are great, but they make it easy to forget how you actually talk to the underyling services. It’s all HTTP under the covers, and that means it’s visible to Fiddler. If all your data is in Azure storage then you can easily see all your traffic and quickly spot bad behavior.

The obvious first step is to go get Fiddler. (If you’ve already been using it for a while this might be a good time to drop some cash in the tip jar for a great tool.) Once you’ve got Fiddler installed, start it up. You may want to close some of your browser windows to keep extraneous traffic from cluttering up your window.

You’ll probably need to change your storage connection strings. If you’re running against development storage then the client libraries will bypass Fiddler. Change your connection string to:

UseDevelopmentStorage=true;DevelopmentStorageProxyUri=http://ipv4.fiddler

If you’re running against an actual Azure storage account then you’re probably using an HTTPS connection. Fiddler won’t look inside HTTPS connections by default, but you can configure it to do so.

That should be all you need. Run one of your unit tests and you should see storage traffic show up in Fiddler. For example:

Fiddler Initial Setup

You should run through your app and watch for bad behavior, such as repeated or unnecessary calls. In future posts I’ll give a few specific examples I’ve seen.