Connecting to the new Azure Caching (DataCache, DataCacheFactory, & Connection Pooling)

Question

The Windows Azure Caching Document says

If possible, store and reuse the same DataCacheFactory object to conserve memory and optimize performance."

Has anyone seen any metrics or any quantification of how expensive this is?

One argument is that

"MaxConnectionsToServer setting... determines the number of chennels per DataCacheFactory that are opened to the cache cluster."

So if MaxConnectionsToServer = 1 and DataCacheFactory is a singleton in your app, then you've effectively syncronized all requests to your web server!

However, there is a lot of indication that DataCacheFactory should be a singleton (i.e. put in Application_OnStart).

This is critical and I can't believe it is not in the Microsoft documentation. Is the DataCacheFactory treated the same in AppFabric, Azure Shared Caching, and Azure Caching? I just have a difficult time believing that Microsoft designed caching in a way that requires a singleton factory object. This is like requiring anyone that uses SqlConnection to have a singleton SqlConnectionFactory object in their application.

So, considering a relatively average web app (For example, 1,000s of requests per hour, ~ 100 objects in cache, the average request accesses 5 cached objects):

1. By default (and recommendation) how many Factory objects should there be at one time?
2. How long does it take to create a DataCacheFactory reference?
3. How long does it take to create a DataCache reference?
4. Should their only be 1 DataCacheFactory object per app and only 1 DataCache reference per request?

---

EDIT (answers in progress):

(1/2). Let Azure connection pooling handle the Factory objects

(3). Still testing...

(4). Still trying to figure out if I should re-use DataCache references

Answer 1

How about that, Microsoft did document best practices and it does involve connection pooling! Although not easy to find (at least for me).

It appears that the answer is simply to not use the DataCacheFactory object when implementing the newer Azure Caching and just access the DataCache object directly

"There are also new overloads to the DataCache constructor that make it simpler to create a cache client. In the past, it was always necessary to create a DataCacheFactory object that returns the target cache. Now it is possible to create the cache with the DataCache constructor directly. The following example creates a client to the default cache from the default section of the configuration file."

DataCache cache = new DataCache();

And to use connection pooling.

"With the latest Windows Azure SDK, connection pooling is enabled by default when you define your cache settings in the application or web configuration files. Because of this default behavior, it is important to set the size of the connection pool correctly. The connection pool size is configured with the maxConnectionsToServer attribute on the dataCacheClient element."

I wish Microsoft gave some guidance on how to configure the maxConnectionsToServer correctly but that can be determined through testing. The automatic connection pooling with the new Azure Caching is pretty cool :)

Answer 2

I'm assuming you're referring to Shared Caching Service (previously known as Azure AppFabric Cache) There is no cost per an individual connection. However, when you purchase a Cache account, you're paying not for only the size of a cache account but also for a particular number of connections.

Smallest cache account has 10 connections per hour, while most expensive one allows for 160 concurrent connections. Thus, if you're concerned that you may run out of connections given the size of your account, it maybe prudent to be careful as to how many connections you open from your app.

More details http://msdn.microsoft.com/en-us/library/windowsazure/hh697522.aspx