Finding Memory Leaks in Azure

Tracking down memory leaks isn’t anyone’s idea of a good time.  There are a lot of great articles out there, but they can be hard to find, and some of them are getting a little long in the tooth. Things have changed since 2004! It turns out that you can find memory leaks in your Azure apps without too much effort, and without buying any tools. Here’s how.

Written by Brian Reischl

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

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.

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!

Written by Brian Reischl

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=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:

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.

Written by Brian Reischl

Getting Started with Glassboard

Glassboard is all about sharing privately with different groups of people you know, so if you’re used to non-private apps, you may wonder how to get started with Glassboard.

You can’t search for people you know like you would on Twitter or Facebook. You can’t even search for groups to join since every group is private.  You have to be invited to a group to know it even exists.

But getting started with Glassboard is easy if you forget the idea that you’re supposed to share with everyone.  Glassboard isn’t designed for that.  It’s designed for sharing only with the people you want to share with.

The first thing you do is create a board (that’s what we call a group in Glassboard).  After you create a board, invite some people to it.  They’ll be the only people who can see what’s posted to that board.

Perhaps you want to share pictures of your kids with your extended family?  Create a board and invite your family to it, without worrying that your pictures will show up in a Google search.

Working on a project that you don’t want the world to know about just yet?  Create a board and invite your co-workers to it.  That’s what we did – we created a board just for those working on Glassboard, and we freely shared ideas in private.  We built our app using our app, and it worked wonderfully.

Or maybe you’re at a concert and you know a bunch of your friends are there somewhere.  Create a board, invite your friends to it, then share messages, photos and videos of the show.  When it’s over, you can even delete the board and know that it’s gone forever.

There are countless examples of other boards you’d create in Glassboard, but it all boils down to this: after you install the app, create a board and invite only the people that should belong to it.  Then enjoy the private conversation.

Written by Nick Bradbury

Glassboard Android Public Beta

Hi folks, this is Nick Bradbury.  You may know me as the Windows developer who created HomeSite, TopStyle and FeedDemon, but a few months ago I made the switch to Android development.

That was when I joined my good friends at Sepia Labs, and set out to create the Android version of Glassboard.  It’s been a lot of work, but today I’m thrilled to announce that the first public beta is available.

So what is Glassboard?  Glassboard is a social sharing app for Android and iPhone.  Yeah, I know – that sounds like a lot of apps these days.  But what sets Glassboard apart is its focus on private sharing.

Facebook and Twitter are wonderful – I share things on them every day.  But there are many things I don’t share because I only want to share them with specific people.

This is where Glassboard comes in.  When you create a group on Glassboard, you’re the only one who can invite people to share in that group.  You can create a group containing only the people you want to share with – perfect for sharing with family members, co-workers, or whatever group you want to define without worrying that others will suddenly show up.

Want to try it out?  If you’re using Android 2.2 or later and have the ability to install non-market apps, you can give the beta a spin by visiting this link from your phone.

This is, of course, a beta, which means it’s far from done and may look or act weird in places.  But if you’re willing to try it out, we’d love to know what you think.

Written by Nick Bradbury

Another good one…

This one is from CMSWire.
Like Facebook’s Functionality, But Not Its Privacy Settings? Check out Glassboard
Well said Ms Mosher!

Written by Walker Fenton

Great writeup in ReadWriteWeb

With a title like this – how can you go wrong?

Glassboard: Rock Star Team Regroups From RSS-Land to Tackle Private Mobile Content Sharing

Written by Walker Fenton

Sepia Labs launches

Written by Walker Fenton

Categories

• Android
• Azure
• Press
• Tech

Twitter

Sepia Labs on Facebook

About Sepia Labs
(Meet the Sepians)