what are the best practices in web farms [closed]

Question

When move from single server to web farms, what are the best practices to deal with DB connection and log files and other issues.

Answer 1

Here are a few things to watch for when moving to a web farm:

1. Don't use InProc session state; switch to SQL mode instead (or avoid session state all together)
2. DB connections will be pooled and shared by default; they shouldn't require any explicit management
3. Use the Windows event log for your application-level logging. That makes it easier to collect and view the logs remotely
4. Use a tool like logparser to automate the processing of your IIS logs
5. Once you get beyond 4 or 5 servers, start looking into automated image-based deployment
6. For about 8 servers or less, you can use Network Load Balancing (NLB), which is included with Windows; beyond that, you should look at hardware load balancing.

This is a big topic, though, and that's really just the tip of the iceberg. In case it might be helpful, I write more about the details in my book: Ultra-Fast ASP.NET.

Answer 2

I note that both answers so far have neglected to explicitly call out setting your MachineKey.

This is ridiculously important in a farm scenario where requests could be sent to any server - without this, requests sent to a different server will throw exceptions when failing to decrypt the page's viewstate, and any encrypted session tokens.

Note also that moving from InProc session state may have other issues for you if you're relying on events such as SessionEnd in the global.asax - this will not fire if you're not using InProc sessions.

Another thing to consider is creating a single account for the applications to run under, rather than the default IUsr_MachineName account - makes it easier to manage DB connections (only one account needed in SQL for example) and rules out "incorrect login" type errors everywhere.

Answer 3

One of the big things to worry about is stateless and stateful sessions.

If you have no state then the clustering layer can route a http request to any of your servers. Else session state has to be considered to route your second, third,etc requests back to the same server. So you may endup refactoring bits of your code to end up stateless. e.g. While the user is browsing a table the current cursor can be saved in a browser page hidden variable, to be sent back to the 'farm' for the next or previous page.

DB connections are event driven normally. Each 'farm' server gets a http/ajax request, connects to DB, gets data, disconnects. Only under heavy traffic might a DB connection be cached, but more code, to go wrong, has to be written to manage this.

Log files. Each 'farm' server must dump its own log files to itself as a central server in a cluster is a bad idea as if its down, then extra code has to made decisions. Your log view package can poll all 'farm' servers for log data in date and time ranges.

My 64 cents (inflation) worth