Microsoft Enterprise Library 5.0 Integration Pack for Windows Azure
As far as I understand, cache will be stored in database, and all web roles are sharing same cache which is same as Azure's in-memory distributed caching.
I'm wondering anyone has successfully used Caching Application Block on Windows Azure instead of Azure Caching.
If so, how is the speed? Any noticeably different from Azure Caching.
Thank you for comments!
The caching application block is deprecated (see here). It is replaced by the System.RunTime.Caching namespace. However, SqlDependency is not supported by SQL Azure, so you cannot use the caching namespace either for a database-driven cache.
So your choices boil down to: implement your own local cache by reading from SQL Azure yourself, use Windows Azure cache, or simply read from SQL Azure on demand.
The performance will be much better with the local cache because it is... local :). A background thread (that you need to write) will refresh your cache on a specific frequency. So accessing the local cache will be going at memory access speed. But... it will not be synchronized perfectly across your Windows Azure nodes, because each node will have its own cache. To work around this issue, you could code your refresh logic in a way that it is done at the same time across all your nodes.
Reading from the Azure Cache will be slower than accessing the local cache, but all your Windows Azure nodes will have access to the same data at the same time. You still need to build a thread that will update the Windows Azure cache on a specific frequency; it won't refresh itself automatically.
Warning: keep in mind that Azure Cache works well if you know in advanced the key of your key/value pair cache entry. In other words, you have no way of getting the list of keys from the Azure Cache. For example, if you store a list of Zip Codes / Temperature, the zip code would be your key (which is a known set). So you could use the Azure Cache for this purpose. The Azure Cache was designed to help store ASP.NET session state, which also has a known key (the Session ID).
Finally, keeping your data in SQL Azure (or another store, like an Azure Table) may work very well too. However that depends on how much traffic you get and how many times you will read from the data source. Remember that in some cases building a caching mechanism is be more work than necessary.