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

2

7

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

Popular answered 14/3, 2013 at 0:30 Comment(3)
Are there any updates on regarding questin 3/4? Do you create a DataCache for each request?Quinn
Robar, we found that creating a DataCache reference with each request was inexpensive once we moved to cache connection pooling.Popular
However, we found that caching didn't solve our underlying problems which were related to SQL Azure performance so we are no longer using Azure. If you need a high-performance transactional database expect to have problems with SQL Azure. If you have a content management system (i.e. mostly reads) I'd guess caching should solve your problems.Popular
P
11

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 :)

Popular answered 15/3, 2013 at 23:53 Comment(3)
Not easy to find indeed. Not anymore though thanks to your question and answer on stackoverflow!Rorry
Both links are dead now. I found this link which appears to be similar: Understand and Manage Connections for Azure Managed Cache ServiceGuard
Indeed both links are dead, how nice of Microsoft. The most relevant part of the dead documents are quoted above. This article covers the basic material: msdn.microsoft.com/en-us/library/hh552970.aspxPopular
E
1

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

Ema answered 14/3, 2013 at 0:44 Comment(1)
Igorek, I'm actually referring to the newer Windows Azure Caching, but programming against the two seem very similar (even though the configuration and architecture may differ significantly). I updated the question to make it more clear and added several links. Thanks!Popular

© 2022 - 2024 — McMap. All rights reserved.