AppFabric Caching - Proper use of DataCacheFactory and DataCache

Question

I am looking for the most performant way to arrange usage of the datacache and datacache factory for AppFabric caching calls, for between 400 and 700 cache gets per page loa

Answer 1

Do I call GetCache("cacheName") for every DataCache object request, or do I make one static at the time DataCache factory is initialized and use that for all calls?

I suppose really the answer should be; try it both ways and see if there's a difference, but one static DataCache seems to me to make more sense than a corresponding call to GetCache for every call to Get.

That 'Pushing Client Performance' article suggests that there's a sweet spot where the number of DataCacheFactory instances gets you maximum performance beyond which the memory overhead starts working against you - it's a shame they didn't give any guidelines (or even a rule of thumb) on where this spot might be.

I haven't come across any documentation on maximising performance - I think AppFabric is still too new for these guidelines to have been shaken out yet. I did have a look in the Contents for the Pro AppFabric book, but it seems much more concerned generally with the workflow (Dublin) side of AppFabric rather than the caching (Velocity) piece.

One thing I would say though: is there any possibility for you to cache 'chunkier' objects so you can make fewer calls to Get? Could you cache collections rather than individual objects and then unpack the collections on the client? 700 cache gets per page load seems to me to be a huge number!

Answer 2

Here is the answer from the forum post:

Hi. Sorry for the delayed response, but I want to say that these are great questions and will probably be useful to others.

There shouldn't be a need for more than one DataCacheFactory per thread unless you are requiring different configurations. For example, if you programmatically configure the DataCacheFactory with the DataCacheFactoryConfiguration class, then you might want to create one that has local cache enabled and another that does not. In this case, you would use different DataCacheFactory objects depending on the configuration you require for your scenario. But other than differences in configuration, you should not see a performance gain by creating multiple DataCacheFactories.

On the same subject, there is a MaxConnectionsToServer setting (either programmatic in DataCacheFactoryConfiguration or in the application configuration file as an attribute of the dataCacheClient element). This determines the number of chennels per DataCacheFactory that are opened to the cache cluster. If you have high throughput requirements and also available CPU/Network bandwidth, increasing this setting to 3 or higher can increase throughput. We don't recommend increasing this without cause or to a value that is too high for your needs. You should change the value and then test your scenario to observe the results. We hope to have more official guidance on this in the future.

Once you have a DataCacheFactory, you do not need to call GetCache() multiple times to get multiple DataCache objects. Every call to GetCache() for the same cache on the same factory returns the same DataCache object. Also, once you have the DataCache object, you do not need to continue to call DataCacheFactory for it. Just store the DataCache object and continue to use it. However, do not let the DataCacheFactory object get disposed. The life of the DataCache object is tied to the DataCacheFactory object.

You should never have to worry about contention with Get requests. However, with Put/Add requests, there can be contention if multiple data cache clients are updating the same key at the same time. In this case, you will get an exception with an error code of ERRCA0017, RetryLater and a substatus of ES0005, KeyLatched. However, you can easily add exception handling and retry logic to attempt the update again when errors such as these occur. This can be done for RetryLater codes with various substatus values. For more information, see http://msdn.microsoft.com/en-us/library/ff637738.aspx. You can also use pessimistic locking by using the GetAndLock() and PutAndUnlock() APIs. If you use this method it is your responsibility to make sure that all cache clients use pessimistic locking. A Put() call will wipe out an object that was previously locked by GetAndLock().

I hope this helps. Like I said, we hope to get this type of guidance into some formal content soon. But it is better to share it here on the forum until then. Thanks!

Jason Roth