This documentation is archived and is not being maintained.

Azure In-Role Cache FAQ

Updated: August 25, 2015

Microsoft recommends all new developments use Azure Redis Cache. For current documentation and guidance on choosing an Azure Cache offering, see Which Azure Cache offering is right for me?

In-Role Cache provides the ability to host caching within your Azure roles. The cache is distributed across the instances of the role that hosts the cache. The size of the cache is determined by several variables. First, the size is dependent on the number of running instances of the role that has In-Role Cache enabled. It is also dependent on the size of those virtual machines and the percentage of memory that is devoted to In-Role Cache on the role. In-Role Cache on Azure roles supports additional features, such as high availability, regions, notifications, and multiple named caches.

For more information on role-based In-Role Cache, see the following resources.

The In-Role Cache binaries are part of the latest Azure SDK. Download and install the latest Azure SDK and Visual Studio tools to obtain everything necessary for In-Role Cache.

Yes. In-Role Cache was released with the SDK.

In-Role Cache is not provisioned through theAzure Management Portal. Instead, In-Role Cache is configured as part of your cloud service deployment.

In-Role Cache is provisioned as a part of your cloud service deployment. In-Role Cache is enabled on a role that provides caching to all of the roles in the same deployment. You can enable In-Role Cache through the Caching tab of the role properties in Visual Studio. For more information, see Configure Caching on Azure Roles.

There is no premium associated with In-Role Cache. Instead, you are billed using standard pricing for compute time for Azure role instances. For example, if you had three web role instances running your ASP.NET web site, it is possible that you could use the extra memory on those instances for caching. In this example, there would not be additional charges for using caching on the existing web role. However, you might find that you need to add an additional web role instance or a dedicated In-Role Cache role. In this case, you would be charged for the additional running role instances that you require for caching.

With In-Role Cache, a percentage of memory from each role instance contributes the total memory available for caching. There are two ways to change the cache size. First, you can change the percentage of memory reserved for caching on the role. Second, you can increase or decrease the amount of memory available for caching by increasing or decreasing the number of instances of the role that has In-Role Cache enabled. The Azure Management Portal supports the ability to make this change to a running cloud service. The actual change in memory is dependent on the virtual machine size for the target role and the percentage of memory allocated for In-Role Cache.

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 using the simple API. You can also configure the cache as a provider for ASP.NET session state and page output.

There are two main ways a role can host In-Role Cache: co-located and dedicated. In the co-located topology, the role that hosts In-Role Cache also hosts other web role or worker role functionality. The memory and resources of the role are shared between caching and non-caching application code and services. In the dedicated topology, which is supported for worker roles, the worker role only hosts caching. These caching topologies differ primarily in the percentage of memory that is dedicated to caching. For more information, see the topics on co-located Caching roles and dedicated Caching roles.

There are no defined usage quotas for In-Role Cache. However, the amount of memory and performance of the cache is constrained by physical resources. For example, caching uses physical memory only. It is not possible to use more physical memory than the combined available memory on the virtual machine instances. It is also possible to have constraints for other physical resources. For example, if a worker role uses a high amount of processing time, adding In-Role Cache to that role could result in poor caching performance.

By using roles for caching, you have the control and flexibility to configure caching in the best way for your application with no predefined quotas.

See Also