Hosting In-Role Cache on Existing Roles (Azure Cache)
Updated: July 17, 2010
|For guidance on choosing the right Azure Cache offering for your application, see Which Azure Cache offering is right for me?.|
This topic covers the ability to host In-Role Cache on existing roles within your application. In this context, an existing role refers to a web or worker role that is also being used for other application code or services. This type of caching topology is also referred to as co-located, because the cache is located on roles that also serve other functions.
For a downloadable sample that uses a co-located topology, see Caching Session State and Output Caching Sample.
Understanding Co-located In-Role Cache
Each role can run on one or more instances. Virtual machines that host these role instances each have a specific amount of physical resources, such as memory. The virtual machine size setting determines the specific values. Co-locating the cache on an existing role occurs when you specify that a percentage of memory on each virtual machine to use for caching.
|Although only memory is specified, the caching functionality uses other physical resources, such as processor and network resources.|
To Enable Co-located In-Role Cache on a Role
The following steps describe how to enable In-Role Cache on a co-located role in Visual Studio.
In Solution Explorer, locate the Roles folder. Double-click the role to use for In-Role Cache.
In the properties window, go to the Caching tab.
Select the Enable Caching checkbox.
Select the Co-located Role radio button, and then configure the Cache Size (%) slider. The following screenshot shows the dialog settings.
Click the ellipsis button to select a storage account to maintain the cache cluster's runtime state.
Then configure the settings for the
defaultcache, or create new named caches.
Guidelines for a Co-located Caching Topology
The following guidelines apply to the co-located In-Role Cache architecture:
Use diagnostics data to determine the correct percentage of memory to allocate for caching. Include performance counter data on memory and CPU for the virtual machine instances that are running under expected load. The amount of memory available per running role instance is determined by the virtual machine size (VM size) and the memory used by the operating system and other application services running on the role. To understand how to correctly set the Cache Size (%), see Capacity Planning Considerations for In-Role Cache (Azure Cache).
A co-located topology is not recommended in the following cases:
Cache sizes greater than 1.5 GB.
Cache clusters with more than 400 caching transactions per second per role instance
Cache clusters with more than 1.2 MB of bandwidth used for caching operations per second per role instance.
Important The metrics in this section provide a general guideline for making a decision on the type of caching deployment topology. You are responsible for testing and monitoring your cloud service to make sure that it meets your requirements. If there are memory shortages or excessive transient error conditions, there are two common mitigations. You can increase the number of running instances for the role that hosts caching. You can also move from a co-located topology to a dedicated topology. For more information about troubleshooting, see In-Role Cache Troubleshooting and Diagnostics (Azure Cache).
- Cache sizes greater than 1.5 GB.
If you are migrating from Shared Caching to caching on roles, the co-located architecture might provide a simplified transition. In this scenario, it is not necessary to add any new roles to the existing deployment. Instead, enable caching on any existing web or worker role in the service. However, based on the guidelines in this section, it might still be advantageous to add a new dedicated role for caching. For more information about this scenario, see Migrate from Azure Shared Caching to In-Role Cache.
Only one cache cluster is supported for each cloud service.