Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question
Hi, firstly, I reckon it is called web form... Secondly, this is too large a topic to discuss with, maybe consult a book? –  Michael Mao Dec 4 '09 at 4:35
@Michael, a web form is something you fill in, a web farm is a distributed series of web servers. My best practice for web farms is to only feed your webs the best natural-grain food and, when it comes times to eat them, make sure you kill them humanely. Boom boom, thanks for listening, I'm here all week :-) –  paxdiablo Dec 4 '09 at 4:41
I'm quite sure OP meant web farms (without animals) :P –  o.k.w Dec 4 '09 at 4:43
@o.k.w:of course a web farm has animals. How could you harvest webs without spiders to spin them? –  Jerry Coffin Dec 4 '09 at 4:52
@jerry: you are right, I meant domesticated ones :P –  o.k.w Dec 4 '09 at 10:41
show 1 more comment

migrated from stackoverflow.com Dec 4 '09 at 20:01

This question came from our site for professional and enthusiast programmers.

closed as not a real question by Mark Henderson Jan 15 '12 at 5:34

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

3 Answers

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.

share|improve this answer
+1 for Session State comment - however you might want to mention that this has other implications (i.e. the SessionEnd event no longer fires). –  Zhaph - Ben Duguid Dec 4 '09 at 11:41
I've gotten rid of session and viewstate... It really does improve the performance but you gotta be a baker to handle all those cookies! –  Cyril Gupta Dec 4 '09 at 11:47
There are possible alternatives to cookies for some apps -- Silverlight isolated storage can be a very interesting one. –  RickNZ Dec 4 '09 at 12:48
Another +1 for the (avoid session state altogether) comment. –  Chris Lively Dec 4 '09 at 22:13
add comment

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.

share|improve this answer
+1 good point re: MachineKey. There are a number of small details like that which can bite you. –  RickNZ Dec 4 '09 at 12:45
Yep, and it's because I've been caught out in the past that I remember about it ;) –  Zhaph - Ben Duguid Dec 4 '09 at 16:33
Considering this is one of the very first problems people encounter, maybe it was left out as an excercise for self discovery... ;) –  Chris Lively Dec 4 '09 at 22:13
add comment

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

share|improve this answer
add comment