Getting Started with the Windows Azure Cache

Windows Azure has a great caching service that allows applications (whether or not they are hosted in Azure) to share in-memory cache as a middle tier service.  If you’ve followed the ol’ Velocity project, then you’re likely aware this was a distributed cache service you could install on Windows Server to build out a middle tier cache.  This was ultimately rolled into the Windows Server AppFabric, and is (with a few exceptions) the same that is offered in Windows Azure.

The problem with a traditional in-memory cache (such as, the ASP.NET Cache) is that it doesn’t scale – each instance of an application maintains their own version of a cached object.  While this has a huge speed advantage, making sure data is not stale across instances is difficult.   Awhile back, I wrote a series of posts on how to do this in Windows Azure, using the internal HTTP endpoints as a means of syncing cache.

On the flip side, the problem with building a middle tier cache is the maintenance and hardware overhead, and it introduces another point of failure in an application.  Offering the cache as a service alleviates the maintenance and scalability concerns.

The Windows Azure cache offers the best of both worlds by providing the in-memory cache as a service, without the maintenance overhead.   Out of the box, there are providers for both the cache and session state (the session state provider, though, requires .NET 4.0).  To get started using the Windows Azure cache, we’ll configure a namespace via the Azure portal.  This is done the same way as setting up a namespace for Access Control and the Service Bus:

Selecting new (upper left) allows you to configure a new namespace – in this case, we’ll do it just for caching:

Just like setting up a hosted service, we’ll pick a namespace (in this case, ‘evangelism’) and a location.  Obviously, you’d pick a region closest to your application.  We also need to select a cache size.  The cache will manage its size by flushing the least used objects when under memory pressure. 

To make setting up the application easier, there’s a “View Client Configuration” button that creates cut and paste settings for the web.config:

In the web application, you’ll need to add a reference to Microsoft.ApplicationServer.Caching.Client and Microsoft.ApplicationServer.Caching.Core.  If you’re using the cache for session state, you’ll also need to reference Microsoft.Web.DistributedCache (requires .NET 4.0), and no additional changes (outside of the web.config) need to be done.  For using the cache, it’s straightforward:

 using (DataCacheFactory dataCacheFactory =
          new DataCacheFactory())
{
    DataCache dataCache = dataCacheFactory.GetDefaultCache();
    dataCache.Add("somekey", "someobject", TimeSpan.FromMinutes(10));
}

If you look at some of the overloads, you’ll see that some features aren’t supported in Azure:

That’s it!  Of course, the big question is:  what does it cost?  The pricing, at the time of this writing, is:

One additional tip:  if you’re using the session state provider locally in the development emulator with multiple instances of the application, be sure to add an applicationName to the session state provider:

 <sessionState mode="Custom" customProvider="AppFabricCacheSessionStoreProvider">
  <providers>
    <add name="AppFabricCacheSessionStoreProvider" 
         type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, 
         Microsoft.Web.DistributedCache" 
         cacheName="default" useBlobMode="true" dataCacheClientName="default"
         applicationName="SessionApp"/>
  </providers>
</sessionState>

The reason is because each website, when running locally in IIS, generates a separate session identifier for each site.  Adding the applicationName ensures the session state is shared across all instances.

Happy Caching!