Web Farms in ASP.NET: Advantages and Issues

Web Farm: When we host a web application over multiple web server to distribute the load among them is called Web Farm. Web Farms are Load Balanced.

Need of Web Farm: After developing our asp.net web application, we host it on web server.  Now one standalone server is sufficient to process ASP.NET Request and response for small web sites but when the site comes for big organization where there an millions of daily user hits then we need to host the sites on multiple Server. This arises the need of web farms. You can increase the number of servers in web farms as your traffic increases.

Role of Load Balancer in Web Farms: Load Balancer IP is exposed to external worlds to access. So whenever some request will come to server from clients, it will first hit the Load Balancer, then based on the traffic on each server Load Balancer distribute the request to corresponding web server. These web servers may share same database server or may be they can use replicated server in the back end.

Advantages of Web Farm

1. It provides high availability. If any of the servers in the farm goes down, Load balancer can redirects the requests to other servers.
2. Provides high performance response for client requests.
3. Provides Better scalability of the web application and reduce the failure of application.
4. Session and other resource can be stored in a centralized location to access by the all server.

Issues with Web Farms:

There are many issues with web farms:

1.State management (Cookies, ViewState, Sessions etc)
2.Caching and Cache invalidation
3.Database loading (managing round-trips, partitioning, disk subsystem, etc)
4.Application pool management (WSRM, pool resets, partitioning)
5.Deployment
6.Monitoring

How to manage Session in Web Farm Mode?

Let’s take an example:

When a user selects an item from a DropDownList and then clicks a submit button, the Click event on the button redirects them to the value of the selected item. This works fine if you are on Webserver1 and the button click PostBacks to Webserver1. If you are on Webserver1 and the load balance submits back to Webserver2, the page reloads and the Button click event never fires.

Solution: While using session, requests are distributed among different servers. By default session mode is set to In Proc where session data stored inside worker process memory. But, In Web farm mode we can share the session among the entire server using a single session store location my making it Out proc (State Server or SQL Server Mode). So, if some of the server goes down and request transferred to the other server by the Load balancer session data should be available for that request.

How to solve caching issues? Centralized Cache location

One Cache-application is to be created, which will take care of the caching and returning the cached items. And that is to be placed in centralized location. All applications should send the data to be cached, to that cache-application. The Cache-application will store the data. When any application requests the cached data, it will be retrieved from the Cache-application. (The centralized Cache-application can be called with credentials.)

SQL server caching

SQL Server caching is easy to implement by using ADO.NET and the .NET Framework, and it provides a common development model to use with existing data access components. It provides a robust security model that can easily be configured to work across a Web farm using SQL Server replication.

If the application requires cached data to persist across process recycles, reboots, and power failures, in-memory cache is not an option. In such cases, Caching mechanism based on a persistent data store, such as SQL Server or the NTFS file system. It also makes sense to use SQL Server to cache smaller data items to gain persistency.

Because the cache service needs to access SQL Server over a network and the data is retrieved using database queries, the data access is relatively slow. We need to carefully compare the cost of recreating the data versus retrieving it from the database.

Monitoring: To detect problems that affect a single server or the whole site, you must monitor both the external URL for the site and the URLs for each of the Web servers.

Synchronize Configuration and Content:

You need to ensure that the config files are present in the right path on all the servers, and that their contents are continuously in sync.