Profiling Azure Storage with Fiddler part 3: Don’t Repeat Yourself

In previous posts I’ve talked about profiling your Azure Storage transactions with Fiddler, and one particular problem to look for. In this post I’ll talk about a more common problem; getting the same piece of data repeatedly. This is always a performance problem, as your app wastes extra time waiting for responses from the storage mechanism. It’s also a scalability problem, because you’re making that storage mechanism work harder than it needs to. Although the problem is not unique to Azure Storage, there is a new twist: you’re paying for each storage transaction. Hitting storage too much hits you directly in the wallet, so it’s more important than ever that you optimize your data access logic.

To demonstrate the problem I have set up my Glassboard API instance to do no caching whatsoever. I then ran a unit test which simulates a user getting his Newsfeed, then posting a status. I highlighted each set of repeated calls in a different color.

Just look at all those colorful, repeated requests! There are 8 requests there, slowing down our app and sucking up money.

Depending on your application there are many possible ways to get rid of repeated requests. You may be able to design them out of the system, share data between layers, or implement local or distributed caches. We used a combination of all of these to fix our problem in Glassboard. With our caching re-enabled, the same test results in this HTTP trace.

 

Written by Brian Reischl