Understanding Quotas for Windows Azure Shared Caching
Updated: February 28, 2014
This topic explains the basic concepts about resource quotas for Windows Azure Shared Caching. Caches use resources such as memory, processor, and network. When you create a Windows 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 Windows Azure FAQ.
|These resource quotas do not apply to In-Role Cache on Windows Azure roles. For more information, see In-Role Cache FAQ (Windows Azure Cache).|
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 Windows 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 Windows Azure Management Portal.
Shared Caching network quotas have three variations:
To understand the connection quota, see Understanding and Managing Connections in Windows Azure Cache. For the other areas, refer to the Windows 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.
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:
Microsoft.ApplicationServer.Caching.DataCacheException: 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 Windows Azure Management Portal. Another strategy is to change the application cache access patterns or amount of data stored in the cache.