1

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

6
  • 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, 2009 at 4:35
  • 2
    @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 :-)
    – user12022
    Dec 4, 2009 at 4:41
  • I'm quite sure OP meant web farms (without animals) :P
    – o.k.w
    Dec 4, 2009 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, 2009 at 4:52
  • @jerry: you are right, I meant domesticated ones :P
    – o.k.w
    Dec 4, 2009 at 10:41

3 Answers 3

5

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.

3
  • 2
    +1 good point re: MachineKey. There are a number of small details like that which can bite you.
    – RickNZ
    Dec 4, 2009 at 12:45
  • Yep, and it's because I've been caught out in the past that I remember about it ;) Dec 4, 2009 at 16:33
  • 1
    Considering this is one of the very first problems people encounter, maybe it was left out as an excercise for self discovery... ;)
    – NotMe
    Dec 4, 2009 at 22:13
4

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.

4
  • +1 for Session State comment - however you might want to mention that this has other implications (i.e. the SessionEnd event no longer fires). Dec 4, 2009 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! Dec 4, 2009 at 11:47
  • There are possible alternatives to cookies for some apps -- Silverlight isolated storage can be a very interesting one.
    – RickNZ
    Dec 4, 2009 at 12:48
  • Another +1 for the (avoid session state altogether) comment.
    – NotMe
    Dec 4, 2009 at 22:13
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