Eksportér (0) Udskriv
Udvid alt
Dette indhold er ikke tilgængeligt på dit sprog, men her er den engelske version.

Understanding Quotas for Azure Shared Caching

Updated: June 19, 2014

Please note the Azure Shared Caching service will be retired on September 1, 2014 and with it the Azure Silverlight-based portal. Once the Shared Caching service is retired, all remaining Shared Cache deployments will be deleted. Microsoft strongly encourages you to migrate at the earliest opportunity all existing Shared caches to either the Managed Cache Service (currently in GA) or to the new Azure Redis Cache (currently in Preview). For migration guidance, including guidance for migrating without making code changes, see Migrate from Shared Caching. For more information about the current Azure Cache offerings, see Azure Cache.

This topic explains the basic concepts about resource quotas for Microsoft Azure Shared Caching. Caches use resources such as memory, processor, and network. When you create a Microsoft Azure cache, there are several quotas that regulate your use of these resources. The numeric limits associated with each cache offering are subject to change, but the Azure team blog provides updated quota information over time. For more information, see the section on caching quotas in the Azure FAQ.

These resource quotas do not apply to In-Role Cache on roles. For more information, see In-Role Cache FAQ (Azure Cache).

Memory Quota

When you create a new cache, you have the option of selecting various cache sizes. So it is clear that there is a quota on memory that is equal to size of the cache. When you exceed the size of your cache, the Shared Caching service will evict items in the cache until the memory shortage is resolved. During this time, you could get memory-related exceptions. It is more probable that cached items will be evicted without any client exceptions. However, those missing items in the cache could lead to other application exceptions or unexpected behaviors.

Items are serialized before being added to the cache, and the serialized items are typically larger than the memory they occupy at runtime. The maximum size of a post-serialized object is 8 MB.

It is important to understand that caches in Shared Caching have a default expiration setting of 48 hours. This means that items added to the cache without a specified expiration time will remain in the cache until the 48 hour period has passed or until you have reached the maximum cache size for your offering and eviction occurs. Allowing eviction to occur for least-recently-used (LRU) items can be an acceptable application design strategy. However, this makes it difficult to tell your actual cache usage, because caches with frequent inserts will approach the maximum cache size before eviction takes place. To handle this, you can programmatically specify a smaller time-to-live value for items added to the cache with the API, enabling items to expire sooner than the default setting. If you use this strategy, select appropriate expiration times for different objects to efficiently use your caching memory resources. This also helps you to understand your true peak memory usage. With this said, it is also possible to specify expiration times longer than the default 48 hours if required by your application design. For more information, see Expiration and Eviction (In-Role Cache for Azure Cache).

If you see evidence that your cache size is too small, you can increase the size of your Shared Caching offering by using the .

Network Quotas

Shared Caching network quotas have three variations:

  • Transactions

  • Bandwidth

  • Concurrent Connections

To understand the connection quota, see Understanding and Managing Connections in Azure Cache. For the other areas, refer to the Azure FAQ for specific numbers associated with each of these network quotas. You’ll notice that as the size of your cache offering increases, the limits on these network quotas increase as well.

Quota Hours

Shared Caching transaction and bandwidth network quotas are reset every hour. If you run out of transactions or bandwidth, no further cache operations will be permitted until the next hour. Applications will get exceptions that contain a message similar to the following:

ErrorCode<ERRCA0017>:SubStatus<ES0009>:There is a temporary failure. Please retry later. 
(The request failed because user exceeded quota limits for this hour. If you experience this often, upgrade your subscription to a higher one)

As mentioned in the error text, one solution is to increase the size of your cache offering in the . Another strategy is to change the application cache access patterns or amount of data stored in the cache.

See Also


© 2014 Microsoft