When move from single server to web farms, what are the best practices to deal with DB connection and log files and other issues.
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.
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.
Here are a few things to watch for when moving to a web farm:
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.
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