Caching – We all know the importance of caching in Web applications today. De-stress your backend database servers is not only the need of hour, but an important design decision. Caching is often not that simple, as the choice what to insert in the cache stores becomes critical. It’s like salt in your meal, use too little or a bit extra, and you know….
I am going to start this post by using an application which gets information from the database and displays to the client. We are using the sample of caching from the Azure platform kit (am not taking any credits J ). The reason for that is, it’s simple and we are going to make it even more.
So, we have a simple MVC app, which has a Home controller pulling the data from a Service which queries the products Database. IN a nutshell, the code looks as below:
Every time the user visits the home page he gets to see the list of products which are always fetched from the database. One look at the home page reveals the time it took to get the data from SQL database. Now, I must admit that my roles are running local and connecting to the Azure Database, and in a while I will take this application to Azure too.
Okay, so here I see the data which doesn’t change frequently and is a perfect candidate for my cache store. But, what are my options! In azure, you have a few of them now. I will be talking about the latest one which is still under preview, so please don’t use it for your production applications, but use it if you are starting to build a new app.
In as much I would explain a 3 year old, the Azure caching preview allows you to use the existing running Role instances as cache stores, which is awesome! Why, because now you have the whole of Memory of a role instance that you could use as a cache store. Imagine a small instance: it gives you 1.7 GB of RAM, and that could be your cache store! Lots of space and it lives right next to your application so a really fast access!
Let’s see where we could do that. To begin with you could simply add a new template to your existing azure app, which is as highlighted below. Pretty cool isn’t it; you are getting a whole worker role only to act as your cache store alongside your web role.
After you do that, if you view the Worker Role settings in Visual Studio, it appears as below. There is a new placeholder for specifying the cache settings! And the best part, I could use a few things that we all look for:
- Dedicated Role to be used for Cache (I get everything, well let’s not be greedy and kick the running OS out of his home, for a small instance with 1.7 G of RAM, for caching you can get approx.. 1 GB still a lot, and you will have to refer to a proper capacity planning once you decide to use it, more details here ) or use it as a Co-located Role which means you are sharing it along with the worker role application so you get to specify a %.
- High Availability (We can specify multiple instances so that in case of a worker role going down, our cache data is still available).
- Multiple logical named cache (so my business translates even better to what I store in the cache)
One step at a time. First, we need to start consuming this cache preview, and as you can see I have enabled the Caching checkbox (see above graphic) to say I want to use it. What I have also done is add a logical named cache below with the following settings. Once again, quite simply implying a named logical container where I would want to store my stuff!
Ok, now I would also like to do a bit of web.config changes so that I can consume the Worker Role cache. The easiest thing to do is to simply get to a Nuget package Windows Azure Caching Preview. This will save you the effort of getting all the required references as well as the config changes.
After that, let’s observe the web.config, only 2 changes that is all!!
- The required config section
- The pointer to where the Web site can find the cache store, in this case the name of our Worker Role
With this, it’s all left up to the code to do the remaining work. Let’s see how. In the below code, I have put emphasis on the changes:
With this all I need to do is to deploy and test it. One more thing, I have opted for High Availability so I will go for 2 instances of my Worker Role!. Before we proceed further, I have introduced another helper method, which gets me find Products from the cache belonging to a category. If you see below, when we insert the objects in to cache, we use a TAG as Categrory ID which means if we would like to get all products for a single category, all we need to do is search the tag with that Category ID.
Okay, so we are all set for a cache demo. This time I will deploy the app on Azure. Now, I have 3 Views that I will test
- Home ( Get from Cache)
- ProductsByTag ( Get products from cache but belonging to a Tag which is a Product CategoryID)
- ProductsFromDB ( Get all products from DB)
Here are the results of all Pages as shown below. Now, I know what you must be thinking, there isn’t much that you save from using Cache in a Worker Role, and trust me, in the next post we will use the local cache (to store the cache data in Web Role’s Memory) to make it lightning fast.
The real deal here is not the latency, but the amount of Proc cycles that you have saved on your SQL database for a data that doesn’t change much!, and depending on the load on your servers that could really get you the extra mileage if you plan Caching effectively !.
Also note that using TAGS (Image 3) how effectively you can logically store and access data out of cache.
Till the next post !