Differences Between Caching On-Premises and in the Cloud
Windows Azure Cache was developed from an on-premises Cache solution that shipped with Microsoft AppFabric 1.1 for Windows Server. In most cases, Windows Azure Cache features are a subset of the features provided by the on-premises caching solution of Microsoft AppFabric 1.1 for Windows Server. For more information about Windows Server AppFabric caching features, see Windows Server AppFabric Caching Concepts. Because of this, you can sometimes understand the architecture and behavior of Windows Azure Cache by referencing the on-premises caching documentation. But there are differences. This topic attempts to provide an overview of where Windows Azure Cache differs from the on-premise caching solution.
|It is not supported to install Microsoft AppFabric 1.1 for Windows Server and Windows Azure Cache on the same machine. This can lead to unexpected behavior, including errors during local debugging as well as missing performance counters.|
Cache Provisioning and Administration
With the on-premises solution of Microsoft AppFabric 1.1 for Windows Server, you have to obtain machines, install Windows Azure on each machine, and then create and manage the cache cluster across those machines.
In the cloud solution, Windows Azure handles most of the administration tasks for setting up the cache cluster. With Shared Caching you provision your cache in the Windows Azure Management Portal, and that provides you with the connection and security information required to use the cache. With In-Role Cache on roles, you define your caching requirements in the properties of your Windows Azure roles. For more information, see Getting Started with Development for Windows Azure Cache.
Unlike Microsoft AppFabric 1.1 for Windows Server, Windows PowerShell is not used to manage the provisioned caches or the cache cluster. With Windows Azure, these tasks are done for you. Also, with the on-premise solution, you can grant access to the cache cluster to specific Windows identities, such as a domain account. But with Windows Azure Cache, the security model is based on Access Control or standard Azure role security. For more information, see Security Model (In-Role Cache for Windows Azure Cache).
Windows Azure Cache provides both a session state provider and an output cache provider. This provider differs from the one that shipped with the first release of Microsoft AppFabric 1.1 for Windows Server. It also provides additional features. Because of this, it is important to carefully follow the instructions for modifying the web.config file correctly for Windows Azure Cache. For more information, see ASP.NET 4 Cache Providers for Windows Azure Cache.
Support for On-Premises Caching Features
Windows Azure supports a subset of the caching features available in Microsoft AppFabric 1.1 for Windows Server. The following list describes some of these differences.
Notifications are only supported when using in-role In-Role Cache. Notifications are not supported with Shared Caching. This also means that you cannot use notifications to invalidate the local cache in Shared Caching. For more information, see Notifications (In-Role Cache for Windows Azure Cache).
Expiration and Eviction
Expiration and eviction work the same with in-role In-Role Cache with one exception. In-Role Cache on Windows Azure Cache introduces a sliding expiration policy that renews the expiration time for an item on each access. This is different than the absolute expiration policy. Users now have the option of specifying either policy.
In Shared Caching, items without a specific expiration setting expire after 48 hours. Unlike in-role In-Role Cache or Microsoft AppFabric 1.1 for Windows Server, there is no way to change this default expiration setting for a Windows Azure Cache. However, if you add items to the cache with an explicit expiration time, such as 10 minutes or 7 days, then the cache will honor this expiration value. This can be done with various overloads of the Add and Put methods. Note that the ASP.NET providers automatically use these overloads to provide explicit timeouts for session state and output caching. In either case, when your cache size exceeds the limits of your Shared Caching offering, the least recently used items in the cache are evicted.
Shared Caching also does not support disabling eviction on a cache. Under memory pressure, it is always possible that items could be evicted. Applications should be designed to anticipate that items might be missing and require reloading at any time. If a cache is too small for the application requirements, a larger Shared Caching offering can be configured from the Windows Azure Management Portal.
For more information, see Expiration and Eviction (In-Role Cache for Windows Azure Cache).
High availability is only supported when using in-role In-Role Cache. High availability is not supported with Shared Caching. For more information, see High Availability (In-Role Cache for Windows Azure Cache).
Regions and Tags
Custom regions and tagging are only supported when using in-role In-Role Cache. They are not supported with Shared Caching. For more information, see Regions and Tagging (In-Role Cache for Windows Azure Cache).
In most cases, you can use the same APIs to write cache clients that use Windows Azure Cache or Microsoft AppFabric 1.1 for Windows Server. There are some exceptions due to differences between the two solutions. For a detailed review of the APIs available for Windows Azure Cache cache clients, see Cache API Support in Windows Azure Cache.
Other ResourcesOverview of Caching in Windows Azure