Click here to Skip to main content
15,867,568 members
Articles / Web Development / IIS

State management and ways to handle Cache in a Web Farm/Web Garden scenario

Rate me:
Please Sign up or sign in to vote.
4.95/5 (60 votes)
13 Apr 2011CPOL12 min read 209.4K   111   55
This article gives a brief idea about state management and discusses the variuos approcahes for handling it in a Web Farm/Web Garden scenario.

Table of Contents

Introduction

In this article, I am going to talk about state management but focus mainly on Web Farm and Web Garden scenarios as there are already very good articles available on the topic in CodeProject. Also, I have already written a few articles on state management. Just for the new readers, I am adding the first few sections from my earlier article to give a brief idea about state management. In this article, I'll be discussing about Web Farms/Web Gardens and later will discuss the various approaches to handle cache in a Web Farm/Web Garden scenario.

Basics about state management

As we all know, the web is stateless. A web page is recreated every time it is posted back to the server. In traditional web programming, all the information within a page and controls get wiped off on every postback. To overcome this problem, the ASP.NET framework provides various ways to preserve the states at various stages, like controlstate, viewstate, cookies, session, etc. These can be defined at the client side and server side state management. Please see the image below.

State Management in ASP.NET

Various options maintain the state

In this article, I will be talking about server side state management techniques. First, let's talk about a very basic and key thing, AppDomain, which was introduced in .NET 2.0,

What is AppDomain

An AppDomain can be defined as a light weight process used for security isolation and availability. The AppDomain is hosted on some process and a process can host multiple AppDomains. So one Appdomain can go down/restart without affecting other AppDomains in the same process.

Role of AppDomain in ASP.NET

AppDomain plays a key role in ASP.NET. When ASP.NET receives the first request, the application manager creates an application domain for it. Application domains are very important because they provide the isolation among various applications on a web server, and every application domain is loaded and unloaded separately, and in an application domain an instance of the class HostingEnvironment is created which provides access to information about all the application resources. Here is a pictorial view:

ASP.NET page processing

ASP.NET handling the first request

The AppDomain is responsible for all the server side side management, which means all the data session (InProc mode), application objects/variable cache, all resides in the AppDomain itself. If the AppDomain goes down, all the data in the webserver will be wiped off. Let's have a view:

AppDomaincontains.PNG

All server side state management data resides in the AppDomain

Let's now talk about Web Farm and Web Garden.

What is a Web Farm

A Web Farm is used in highly available applications and which have a lot of users that cannot be served by a single server. They provides better performance and are easily scalable. It means we'll have multiple web servers behind a Network Load Balancer(NLB). Whenever a request comes, it first goes to the load balancer, which checks all the available web servers and finds the web server which has comparatively less requests to serve, and passes the request to that web server. Let's have a pictorial overview.

Web Farm

A Web Farm

Most of the large applications are deployed in a Web Farm scenario. A single server might not able to handle millions of requests in a day, and we provide a virtual IP to the Load Balancer, and the URL is mapped to the Load Balancer; the load balancer takes the decision to pass the request to a specific web server.

In this scenario, the session mode InProc does not work. We need to use the OutProc mode, because if the first request is served by server1 and its stores session data, but later for another request the Load Balancer finds that server1 is busy handling other requests, it can pass the request to another server, which obviously will not have the session data and this can result in a bizarre output.

In OutProc mode, session data is not stored in the AppDomain of the web server. We store the data in another server. We'll discuss it later.

Affinity

There is a setting known as affinity parameter setting, which can be set so that the Load Balancer directs all the requests from one client IP address to the same machine. This allows us to use Session (InProc mode), Application data, and Cache in a Web Farm scenario seamlessly. This means the application would work like it is deployed on a single server. But this has a few limitations like:

  • If the server serving the request goes down in between, all the server data would be lost.
  • This limits the use of a Web Farm as a Load alancer would be confined to redirecting requests for the same client machines to a single web server only.

Have detailed look on the link Click here

What is a Web Garden

When we deploy our application on IIS (6 and above), we assign an application pool to our application. An application pool is used for isolation purposes from other applications deployed on the same web server. An application pool has one worker process (w3wp.exe) normally. An AppDomain is created over this worker process that handles/serves the requests sent by the client machines. All the server data (Session, Cache, Static variables, Application variables) are stored in the AppDomain boundary. But we can have multiple worker processes on the same application pool for performance benefits. This allows better handling for web requests sent by the client machines. But these worker processes do not share the memory and a new AppDomain is created for the same application and each AppDomain will have its own copy of data. This means if some session is stored in an AppDoain's memory and the next request is handled by another web server, it won't have the previously stored session data.

Let's have a pictorial overview.

Application pools

First two application pools show a Web Garden scenario

A Web Garden provides performance benefits in multi-core processor systems taking benefits from other CPUs.

Affinity

Now the question: Do we have some affinity settings in a Web Garden scenario? Yes.

There is a hard-coded client connection affinity to a worker process instance. So for a given client TCP connection, all the HTTP requests will be handled by the same instance of the worker process.

So as we all have seen, in the case of setting the affinity parameter, we can host our application in a Web Farm/Web Garden scenario without worrying about how the web server data is going to be stored and managed. It will work seamlessly as our application is hosted on a single server.

As we discussed the limitations of the affinity parameter, it is understood that it is not advisable to set the affinity parameter.

More about session management

Let's discuss Session a bit. As we know, Session is stored on the web server. First, let's have a quick look at how Session is stored.

There are two modes for storing Session:

  • InProc
  • OutProc

InProc: In this mode, Session values are stored in the AppDomain on the Web server where the application is running. As this is stored in the server memory, it's highly efficient from a performance point of view. But this is not very scalable and robust, because a the users for the application increase, your application may face a tough time processing multiple requests and it can go down. And also for websites that require high availability, this does not work.

OutProc: The data in the Session is not stored in the AppDomain in the Web server memory. And whenever your data goes out from the Web server memory, you need to serialize and deserialize again before using it. There is performance overhead in this as well. The Session is stored in three ways:

  • StateServer: Session information is in a state server in a process known as the ASP.NET state service, that is separate from the ASP.NET worker process. This is a single point of failure. If this service/box goes down, your application will stop working abruptly.
  • SQL Server: We store the session in SQL Server. .NET provides some default scripts that can be used to install the SQL Server and it gets ready to use to store session data. Also, we can have a cluster by maintaining the Session on several machines. So if one goes down, the user requests can be served from another box.
  • Custom aproach: ASP.NET provides us the flexibility to write our own custom provider for maintaining and storing Session data. This allows us to store session data where and how we want.

We have already discussed a lot on these. What about other state management methods like Cache, Application State, static variables? Can we use the Application state in the case of a Web Farm/Web Garden scenario? I have found people not having much ideas about other state management techniques like Application and Cache.

Let's now discuss Cache.

How to handle Cache in a Web Farm/Web Garden scenario

To start with, you must have some basic idea about Cache management in ASP.NET. You can go to the following link which gives you a very good idea about cache management: Exploring Caching in ASP.NET.

How can we handle Cache which resides in the AppDomain in a Web Farm or Web Garden scenario? The best way is to not use Cache in a Web Farm or Web Garden scenario. It all depends on the requirements, and the kind of data you are going to have in your Cache.

If you have really static data, like country names, it is not going to be changed every now and again. In such a case, it does not matter whether it is in a Web Farm/Web Garden scenario. If the data is not available in the AppDomain, it will get loaded from the database. And obviously, it's not going to change once it is loaded and so no more worries.

Now I will discuss some specific scenarios:

Scenario 1

You have some data in a file system. You have lots of data in your config file which is frequently used. Reading repeatedly from the config file would not be a good approach. It's better to have it in the Cache and retrieve it from there whenever required.

Approach

This is a very basic scenario: you can load the data initially when there is no data in the Cache and set the dependency on the file. This means whenever there is a change in a file, the cache will be invalidated and will get updated, and this will be valid for all AppDomains across the Web Farm/Web Garden.

Dependency on File System

Cache with dependency on a file

Scenario 2

Let's say we have some master data that is used by the entire application frequently. It might not be a good approach to get the data the database every time you need it. It's better to have it in the Cache. One more thing, this master can be updated by the Admin with an interface.

Approach

I think this is a very basic requirement and the best candidate for using Cache. The data is almost static and will be updated very infrequently. There is some master data which we can load the first time when it is not in the cache. Their can an admin interface which alone can enter the master and update it in the database. At this point, one need to update the Cache for all the AppDomains on all the web servers. In a Web Farm scenario, your data is coming from database, and you can set the dependency on the database so that as soon as the data gets updated in your database, the cache will be invalidated on all the web servers and will get reloaded with the updated data from database. This is a common scenario and you need not worry about data syncing. Here is a pictorial view.

dbdependency.PNG

Cache with dependency on database

Scenario 3

This is a common scenario: we store some data in the Cache in the server and it get updated at any time. How do we handle this in a Web Farm or Web Garden scenario?

Approach 1

As soon as the data in any of the cache gets updated, it will invoke a Web Service call to all the web servers which will update the cache in all the associated web servers behind the Load Balancer. So here we can have a table in the database which will have the IP of the web server connected in the Web Farm (the IPs will be the direct IPs of the web servers not the load balancer virtual IP). Let's see this in steps.

  • There will a table in the database with the IPs of all the webservers under the load balancer.
  • There will be a Web Service that will get the IPs of all the webservers and update the cache.
  • The Web Service will be invoked by any of the webservers behind the load balancer on which the cache will get updated.

It is also a good idea to add a new webserver under the load balancer to cater to the new needs. Just add the table which has all the IPs of the webservers.

Cache handling with web service approach

Cache handling with the Web Service approach in a Web Farm scenario

Approach 2

In this case, your cache is not on the web server but you can store it on some other server. Every web server is going to connect to this machine to get the cached data. You might ask, if the cache is stored on another box, what will be the performance cost? I would suggest you to have a Remoting (TCP) connection to that caching server and it will be very fast to get data from there, that there would not be much difference in having the data in the same web server's memory or in a cache server.

Remoting Approach

Cache handling with Remoting approach in a Web Farm scenario

Approach 3

This is a very easy one and will cost you money. There are myriad third party tools available which can be used to handle the cache issue on a Web Farm or Web Garden scenario. You can find them with the help of Google.

Feedback and suggestions

Feedback is very important for any author. I request to you all to share your feedback and give me suggestions which would encourage me and help in writing more.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Software Developer (Senior)
India India
Brij is a 3-times Microsoft MVP in ASP.NET/IIS Category and a passionate .NET developer. More than 6 years of experience in IT field, currently serving a MNC as a Tech Lead/Architect.

He is a very passionate .NET developer and have expertise over Web technologies like ASP.NET 2.0/3.5/4.0, jQuery, JSON, Javascript, IIS and related technologies. He is also a Exchange Server (EWS) Specialist. He has great experience in design patterns and N-Tier Architecture.

He is also certified as Microsoft Certified Technologies Specialist-ASP.NET and Microsoft Certified Technologies Specialist-WCF in .NET 4.0. He has also received several awards at various forums and his various articles got listed as "Article of the day" at ASP.NET Microsoft Official Website www.asp.net.

He has done MCA from NIT Durgapur and completed his graduation from Lucknow University.

Learning new technologies and sharing knowledge excites him most. Blogging, solving problems at various forums, helping people, keeps him busy entire day.


Visit his Blog: Code Wala

Area of Expertise :
C#, ASP.NET 2.0,3.5,4.0, AJAX, JQuery, JSON, XML, XSLT, ADO.Net, WCF, Active Directory, Exchange Server 2007 (EWS), Java script, Web Services ,Win services, DotnetNuke, WSS 3.0,Sharepoint Designer, SQL Server 2000/2005/2008

Comments and Discussions

 
GeneralMy vote of 5 Pin
TweakBird10-May-11 18:02
TweakBird10-May-11 18:02 
GeneralRe: My vote of 5 Pin
Brij11-May-11 7:18
mentorBrij11-May-11 7:18 
GeneralMy vote of 5 Pin
raja_krish5-May-11 9:32
raja_krish5-May-11 9:32 
GeneralRe: My vote of 5 Pin
Brij8-May-11 3:43
mentorBrij8-May-11 3:43 
GeneralMy vote of 5 Pin
Marcelo Ricardo de Oliveira24-Apr-11 4:01
mvaMarcelo Ricardo de Oliveira24-Apr-11 4:01 
GeneralRe: My vote of 5 Pin
Brij24-Apr-11 5:58
mentorBrij24-Apr-11 5:58 
GeneralMy vote of 5 Pin
ahmed-itani23-Apr-11 21:45
professionalahmed-itani23-Apr-11 21:45 
Informative straight forward, clear and easy to understand
GeneralRe: My vote of 5 Pin
Brij23-Apr-11 22:14
mentorBrij23-Apr-11 22:14 
GeneralVery Nice Article Pin
Suchi Banerjee, Pune19-Apr-11 5:42
Suchi Banerjee, Pune19-Apr-11 5:42 
GeneralRe: Very Nice Article Pin
Brij19-Apr-11 5:44
mentorBrij19-Apr-11 5:44 
GeneralWindows Server AppFabric should be the way to go Pin
Jacobs7619-Apr-11 2:44
Jacobs7619-Apr-11 2:44 
GeneralRe: Windows Server AppFabric should be the way to go Pin
Brij19-Apr-11 6:01
mentorBrij19-Apr-11 6:01 
GeneralMy suggestion: Windows Server AppFabric Caching Services (aka Velocity) Pin
Gabor Mezo18-Apr-11 21:10
Gabor Mezo18-Apr-11 21:10 
GeneralRe: My suggestion: Windows Server AppFabric Caching Services (aka Velocity) Pin
Brij19-Apr-11 5:51
mentorBrij19-Apr-11 5:51 
GeneralMy vote of 5 Pin
Gandalf_TheWhite14-Apr-11 20:08
professionalGandalf_TheWhite14-Apr-11 20:08 
GeneralRe: My vote of 5 Pin
Brij14-Apr-11 20:40
mentorBrij14-Apr-11 20:40 
GeneralHands down the best! My vote a 5! Pin
bgates197014-Apr-11 3:53
bgates197014-Apr-11 3:53 
GeneralRe: Hands down the best! My vote a 5! Pin
Brij14-Apr-11 3:58
mentorBrij14-Apr-11 3:58 
GeneralMy vote of 5 Pin
koolprasad200313-Apr-11 20:10
professionalkoolprasad200313-Apr-11 20:10 
GeneralRe: My vote of 5 Pin
Brij13-Apr-11 20:18
mentorBrij13-Apr-11 20:18 
GeneralGood job Brij Pin
Surendra Sambana13-Apr-11 18:45
Surendra Sambana13-Apr-11 18:45 
GeneralRe: Good job Brij Pin
Brij13-Apr-11 19:43
mentorBrij13-Apr-11 19:43 
GeneralNice article. Pin
Wonde Tadesse13-Apr-11 4:41
professionalWonde Tadesse13-Apr-11 4:41 
GeneralRe: Nice article. Pin
Brij13-Apr-11 5:05
mentorBrij13-Apr-11 5:05 
GeneralRe: Nice article. [modified] Pin
Wonde Tadesse13-Apr-11 6:19
professionalWonde Tadesse13-Apr-11 6:19 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.