Thursday, August 25, 2011

Web applications are accessed by multiple users. A web site is used to say having low load when number of clients accessing the site is less, where as a web site is used to say having heavy load when number of clients accessing site is very high. Heavy load on the web site slows down the server processing and ultimately latency and response time is reduced. Slow access is the most common problem for any web site when it is accessed by a large number of clients simultaneously. One of the most common reasons for slow access of web site is database operations. Data base operations are the slowest operation performed in asp.net web site applications. Hence frequent visits to database slow down the web site performance. To minimize the database hits, provide faster data access and to provide performance improvement, Caching is used in asp.net.

Need for Distributed Caching -

ASP.NET today has become really popular for high traffic applications and it is very common scenario to see 10-20 servers’ load balanced web farms or sometimes even more. These are nothing but distributed asp.net applications.

As you increase load, you can add more servers to asp.net web farm but you cannot do the same thing with database. Therefore, we can implement caching on a standalone server in asp.net web farm applications. However, “In memory caching” used on a standalone server in case of asp.net distributed applications, proposes many limitation due to restriction of RAM size existing on single server. This leads to the implementation of “Distributed Caching”.

Distributed caching is a form of caching that allows the cache to span across multiple servers so that cache can grow in size and transactional capacity. Distributed caching is scalable because of architecture it employs. The work is distributed across multiple servers but still gives you a logical view of single cache.

Need of Azure App fabric Caching -

Now implementing distributed caching is a cumbersome job. Microsoft had released “Velocity” which implements distributed caching. Now it is popularly known as Microsoft AppFabric Caching. So basically, Microsoft distributed caching is nothing but Microsoft AppFabric Caching.

The problem with Microsoft Windows AppFabric Caching is Maintenance and administration of servers in cache cluster. If you wish to free yourself from the problem of administration, you can go for “Windows Azure AppFabric Cache”.

Most of applications these days are getting migrated to Windows Azure Cloud to get cloud benefits. This saves users from maintenance of on premise asp.net server web farms. So when you have web site hosted in Azure Cloud and you wish to use caching then azure AppFabric cache is the best option.

Windows Azure AppFabric Cache Overview –

App Fabric caching provides a distributed, in-memory, application cache service for windows Azure and SQL Azure applications. It provides applications with high speed access and scale to application data. These capabilities are entirely provided as a Service means user won’t have to worry about installation or management of instances and azure dynamically increases or decreases size as and when needed. Azure app fabric cache can be used when you want to accelerate performance of ASP.NET web applications running on Windows Azure. Also it is useful when you want to decrease the latency of access of data stored in SQL Azure.

Followers

About Me

I am Kunal Chandratre. Working as Cloud Solution Architect @Microsoft. My speciality is Microsoft Azure Cloud platform.
Awarded as Most Valuable Professional (MVP) in Microsoft Azure for consecutive 3 years. Passionate speaker, trainer...In free time (which I don't get usually)I write blogs and answers the forum questions. I was doing it just for timespass but now I have got addicted to blogging...Apart from work, I do variety of things which I can't tell here:).. I am trekker, singer, actor, painter, f1 racer, super hero in my dreams.. ...and now trying my luck with technologies...Keep posting...

Visitors

Disclaimer:

The information shared in this blog is the result of my personal experience with various technology platforms. In no way it represents the company I work for.
The information provided here is "AS IS" with no warranties, and confers no rights. This blog does not represent the thoughts, intentions, plans or strategies of my current employer or past empolyers or any other forums or community I belong to. It is fully my own opinion. Inappropriate comments will be deleted at the authors discretion. All code samples are provided "AS IS" without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.I have full rights to edit/modify/delete any content of this blog without any prior notice to public/followers/RSS readers of this blog.