How to create an ASP.NET web farm?

Question

I am looking for information on how to create an ASP.NET web farm - that is, how to make an ASP.NET application (initially designed to work on a single web server) work on 2, 3, 10, etc. servers?

We created a web application which works fine when, say, there are 500 users at the same time. But now we need to make it work for 10 000 users (working with the web app at the same time).

So we need to set up 20 web servers and make something so that 10 000 users could work with the web app by typing "www.MyWebApp.ru" in their web browsers, though their requests would be handled by 20 web-servers, without their knowing that.

1) Is there special standard software to create an ASP.NET web farm?

2) Or should we create a web farm ourselves, by transferring requests between different web servers manually (using ASP.NET / C#)?

I found very little information on ASP.NET web farms and scalability on the web: in most cases, articles on scalability tell how to optimize and ASP.NET app and make it run faster. But I found no example of a "Hello world"-like ASP.NET web app running on 2 web servers.

Would be great if someone could post a link to an article or, better, tell about one's own experience in ASP.NET "web farming" and addressing scalability issues.

Thank you, Mikhail.

Lamprophyre

I am late but a good starting point is described here: learn.microsoft.com/en-us/iis/web-hosting/… – Attain

Answer 1

1) Is there special standard software to create an ASP.NET web farm?

No.

2) Or should we create a web farm ourselves, by transferring requests between different web servers manually (using ASP.NET / C#)?

No.

To build a web farm, you will need some form of load balancing. For up to 8 servers or so, you can use Network Load Balancing (NLB), which is built in to Windows. For more than 8 servers, you should use a hardware load balancer.

However, load balancing is really just the tip of the iceberg. There are many other issues that you should address, including things like:

1. State management (cookies, ViewState, session state, 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

In case it might be helpful, I cover many of these issues in my book: Ultra-Fast ASP.NET: Build Ultra-Fast and Ultra-Scalable web sites using ASP.NET and SQL Server.

Bathyscaphe

Thank you very much, Richard! And we will try look for information in your book! – Lamprophyre

Richard, Wikipedia says that "NLBS is intended for .. stateless applications" (en.wikipedia.org/wiki/Network_Load_Balancing_Services). Is this information correct or not? Our application is absolutely "stateful"! – Lamprophyre

The statement is technically true, but it's also misleading. HTTP itself is considered to be a "stateless" protocol. The first thing that happens, at a high level, is that each incoming request from clients can be directed to any one of your web servers. That function is performed by NLB or by a hardware load balancer. In order for any server to be able to process each request, your application state can't be stored on a single web server; it either needs to follow the request in some way (such as ViewState), or be included in the HTTP headers (cookies), or be stored in the back-end database. – Bathyscaphe

Does the Microsoft Web Farm Framework not count as "standard software"? iis.net/downloads/microsoft/web-farm-framework – Fallonfallout

Answer 2

I'd say you should configure an NLB cluster (Network Load Balancing), which basically splits all requests between cluster nodes (And as an added benefit detects if things are down and stops sending them requests). There's features built into windows for this, but they don't compare to a hardware device for performance or scalability. If you're using Windows 2008 it really is simple to set one up. If you do this make sure you have a shared machine key or you'll start getting exceptions for viewstate being invalid (When 1 server submits the form and it posts to the other and they're using different keys to encode the data).

You can also use DNS round-robin but at 20 servers presumably in 1 datacenter I wouldn't see a point to going to such crazy lengths. If you've got multiple data centers though this is definitely worth considering (As NLB won't really work well between data centers).

You'll also want to be sure if a user swaps servers they don't loose their session. The simplest way would be to use a Session State database (Configurable in the web.config, or you can do it server-wide in IIS's configs). If you don't use sessions though just turn them off in the Pages directive of the web.config and call it a day. You could also use a session state server, but I don't have any experience with this.

It may also be worth considering spending some time optimizing the code or adding caching directives to static content - it can be very cost-effective even if you only trim the need for a few of those servers.

Hope that helps.

Airfield

Thank you for your answer! We will then start looking for information about NLB and other things you mentionned in your reply. – Lamprophyre

Answer 3

If you keep your server stateless, it is easy with a good router that implements some round-Robbin protocol (that send each call to the single published server ip to a different web server).

if it is not stateless (like - if a login is required, or ssl) than you need to keep each session to the same server.

Here is some info about MS Application Request Routing - you will get everything there:

IIS Load balancing

Trifid

Sticky connections (required for "keep each session to the same server") should be considered a temporary hack at best; they are not scalable, and can introduce a whole host of headaches, including difficulty with capacity planning, lost connections in the event of server failures, etc. – Bathyscaphe

Answer 4

I would not recommend #2. You will do much better off with a load balancer.

Pay attention to session state management. Unless you configure the load balancer to keep each user on the same web server, you will have to use the session state server or database.

Also, check your code's usage of Application and Cache variables. These will be different on every web server. If those values are static, you may not have a problem. But if they can change, you can end up with different values on each web server.

There used to be a problem with ViewState in 1.x, as explained here. I'm not sure if this problem still exists.

Then, there are some changes that you need to make to the Machine Key in web.config, as explained here.

Pule