SalesBuy
1-855-856-7678
Technical SupportSupport
Differences Between Caching On-Premises and in the Cloud
Windows Azure Caching was developed from an on-premises Caching solution that shipped with Microsoft AppFabric 1.1 for Windows Server. In most cases, Windows Azure Caching 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 Caching by referencing the on-premises caching documentation. But there are differences. This topic attempts to provide an overview of where Windows Azure Caching differs from the on-premise caching solution.
 Warning |
|---|
| It is not supported to install Microsoft AppFabric 1.1 for Windows Server and Windows Azure Caching 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 Caching 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 Caching.
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 Caching, the security model is based on Windows Azure Access Control or standard Azure role security. For more information, see Security Model (Windows Azure Caching).
ASP.NET Caching
Windows Azure Caching 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 Caching. For more information, see ASP.NET 4 Caching Providers for Windows Azure.
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
Notifications are only supported when using in-role Caching. 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 (Windows Azure Caching).
Expiration and Eviction
Expiration and eviction work the same with in-role Caching with one exception. Windows Azure Caching 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 Caching 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 (Windows Azure Caching).
High Availability
High availability is only supported when using in-role Caching. High availability is not supported with Shared Caching. For more information, see High Availability (Windows Azure Caching).
Regions and Tags
Custom regions and tagging are only supported when using in-role Caching. They are not supported with Shared Caching. For more information, see Regions and Tagging (Windows Azure Caching).
API Support
In most cases, you can use the same APIs to write cache clients that use Windows Azure Caching 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 Caching cache clients, see Caching API Support in Windows Azure Caching.
See Also
Build Date:
