Windows Azure Shared Caching FAQ

Windows Azure Caching is a distributed, in-memory cache that you can use to accelerate the performance and scale of your cloud applications built on Windows Azure and SQL Database. Caching is often used to keep frequently queried data in-memory close to the application itself, which both reduces overhead on the database tier and also eliminates unnecessary network latency.

ASP.NET developers can use Caching without code changes, as prebuilt session state and output caching providers enable you to activate with simple configuration changes. Caching capabilities are also directly available using a simple API for even more flexible and customized application use. At runtime, Caching transparently distributes ASP.NET session/output cache data or .NET Framework objects stored in the cache across the elastic, scale-out infrastructure.

For more information on Caching, see Overview of Caching in Windows Azure.

No. Windows Azure Shared Caching is a new way of describing the existing multitenant service on Windows Azure. This service had previously been referred to as the Caching Service. The new terminology, Shared Caching, is designed to highlight the fact that backend Caching servers host multiple, isolated caches for multiple users. This distinguishes the service from the new Caching that supports hosting Caching services on Windows Azure roles that are private to a cloud service deployment. For more information about the differences, see How does Shared Caching differ from Caching on Windows Azure roles?.

Because it is delivered as a true service, Shared Caching has a very simple provisioning model. There is no complex infrastructure to install, set up, or manage. The service performs these functions for you. There are only two things to configure: the data that you want to store and how large a cache you need. As the needs of your application grow or decrease, you can dynamically change the size of the elastic cache based on your needs.

You can sign up to use Windows Azure Shared Caching through the Windows Azure Management Portal. For step-by-step instructions, see How to: Create a Cache (Windows Azure Shared Caching).

If you are signed up to one of the Windows Azure Platform offers, you might be eligible to get the 128MB cache option for free for a limited time depending on the specific offer. You can find more details on the Windows Azure Platform Offers page.

The regular prices of the different cache size are the following:

• 128-MB cache for $45.00/month
  
  
• 256-MB cache for $55.00/month
  
  
• 512-MB cache for $75.00/month
  
  
• 1-GB cache for $110.00month
  
  
• 2-GB cache for $180.00/month
  
  
• 4-GB cache for $325.00/month
  
  

Consistent with other Windows Azure Platform services, Shared Caching provides a true Platform as a Service (PaaS) model in which the cost and complexity of installing, configuring, and managing the infrastructure is hidden from you. All you do is provision and configure the service. This means that the total cost of ownership can be lower over the lifetime of your application. The table shown here summarizes several advantages to a service vs. a hosted do-it-yourself solution:

You can sign up and provision more than one cache. A combination of caches adds up to sizes that differ from those that are provided out-of-the-box. It is up to you to select the most cost effective option for your needs.

Yes. You can upgrade or downgrade the cache size that you signed up for after you start to use the cache. If you upgrade to a bigger size cache, existing data in the cache remains intact. If you downgrade, the cache eviction policy removes the least recently accessed data in the cache if necessary.

From a cost perspective, the service is billed monthly based on the cache size you are signed up for. But the charge is calculated on a daily basis. When upgrading or downgrading between cache sizes, you are charged for that month according to the portion of days you were signed up for each cache size.

For example, consider if you were signed up for the 128MB ($45/month) cache for 10 days of the month, and then upgraded to the 256MB ($55/month) cache size for the rest of the 20 days during that month. You pay the total of 45/(10/30) + 55/(20/30) = $51.67 for that month.

You can store any kind of data in the cache. The only requirement is that the data is serializable. This includes but is not limited to:

• Common Language Runtime (CLR) objects
  
  
• Rows
  
  
• XML
  
  
• Binary data
  
  

You can programmatically interact with the cache by using the simple .NET Framework API. You can also configure the cache as a provider for ASP.NET session state and page output.

They are built on the same underlying technology platform. Windows Azure Shared Caching is a service that you can use on Windows Azure. For Windows Azure Shared Caching, Microsoft has created the entire underlying cache infrastructure for you and automated the provisioning and management of the cache on Windows Azure). For more information, see About Windows Azure Shared Caching.

Once you provision a cache of a certain size, Windows Azure Shared Caching limits the amount data you put in the cache to that size. If you try to put more data into the cache than the size you provisioned, Shared Caching automatically removes data to make space. The data deletion process is asynchronous and follows the least recently used (LRU) policy. The process also runs in a controlled manner to achieve maximum efficiency. This intermittent process means your application might temporarily have more data in the cache than the size for which you signed up. But the system will soon correct the situation and delete data from your cache to keep your cache size within the provisioned size.

As with other services in the Windows Azure platform, in order to make sure there is fair usage of resources, the service might enforce limitations based on the number of transactions being made against the cache, the total bandwidth being consumed, or the number of concurrent connections used. If you exceed the limitations enforced by the service, your application receives an exception that specifies the exceeded quota limit.

The following table provides general guidance that can help you plan your usage of the service. This guidance is a high-level estimate and is subject to revision in the future.

Tip
For a detailed explanation of these quotas and how to plan properly for Caching, see Capacity Planning for Caching in Windows Azure.

Windows Azure Caching introduces a new ability to host Caching within your Windows Azure roles. The cache is distributed across the instances of the role that hosts the cache. The main difference from Shared Caching is that role-based Caching is private to your hosted service. With Shared Caching, Caching is offered as a multitenant service. As a result, role-based Caching does not have the quotas that a shared service must have. The size of the cache depends on several variables. First, the size is dependent on the number of running instances of the role that has Caching enabled. It is also dependent on the size of those virtual machines and the percentage of memory that is devoted to Caching on the role. Caching on Windows Azure roles supports additional features, such as high availability, regions, notifications, and multiple named caches. Because it is part of your cloud service, Caching on roles should also have improved performance over Shared Caching.

For more information on the differences, see Overview of Caching in Windows Azure.