This post originated from an RSS feed registered with .NET Buzz by Scott Hanselman. Original Post: Load Balancing and ASP.NET Feed Title: Scott Hanselman's ComputerZen.com Feed URL: http://radio-weblogs.com/0106747/rss.xml Feed Description: Scott Hanselman's ComputerZen.com is a .NET/WebServices/XML Weblog. I offer details of obscurities (internals of ASP.NET, WebServices, XML, etc) and best practices from real world scenarios. Latest .NET Buzz Posts Latest .NET Buzz Posts by Scott Hanselman Latest Posts From Scott Hanselman's ComputerZen.com

Deployed a site this weekend with much success.  A few things that one always needs to remember when putting out a "site" that's on more than one server ("box").

• In-process Session State + More than One Web Server: If you're using in-proc Session on ASP.NET, remember that the session has "affinity" with the server.  That means that if www2.hanselman.com is the first server the user ever hits, the user will get an ASPSESSIONID cookie that is an index into the Cache object (the In-Proc Session is really just a key to a Hashtable-type structure inside the Cache/Application) that only exists in the memory of THAT ONE SERVER.  So, since you're using Load Balancing (you have more than one server) it's important to ensure you're using "sticky connections" or node-affinity to guarantee the user gets back to his/her session on the next HTTP Request. 
  Note that it's often tricky to get a user back to the same box when dealing with "mega-proxies" of large corporations, ISPs, and AOL.  That means that if your load-balancer (hardware or otherwise) is looking at various combinations of IP+VPORT+Whatever that these values MAY CHANGE if the ISP changes their source port or IP address.  If you're using SSL, you can use the SSL ID to route traffic, but this can slow you down a smidge.  You can also let the hardware loadbalancer add in a cookie of its own.  Check your loadbalancer's FAQ for details.  But, it's worth being aware of the things
• Out-of-Proc (State Server) + More than One Web Server: If you are using the State Service, you might think about putting it behind your second firewall, in a different DMZ than both the Web Servers or the Database. 
• Out-of-Proc State Server + ONLY ONE Web Server:  Some folks use the Session State Service even if they have only one Web Server so the session state isn't lost when the ASPNET_WP.EXE process recycles.  If you do this, make sure to lock down the state service to serve local requests only.
  

  HKLM\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnections

  You can also change the port that the state service listens on with the following key:

  HKLM\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\Port

  If you're using the state server in a web farm, it's important that you put it behind a firewall or otherwise prevent anything but the web servers from talking to it. [Early and AdopterEarly and Adopter]

• WebFarm Gotchas: When you're using either the State Service or SQL Server Session State, you're indicating that you don't want "session affinity" and you'll probably set your Load Balancer to Round-Robin dispatching of traffic. (It won't using any smarts or algorithms to get traffic, it will just go 1, 2, 3, etc.)  When you do this AND you're using Forms Authentication OR you have EnableViewStateMAC set to protect your ViewState, remember to synchronize your <machinekey> between all machines in the farm.  As users move around your site, each page could put served up from a different machine, meaning that not only are your encrypted forms-auth cookies passed around, but your ViewState (protected by the machinekey) may be sourced from one machine, and posted to another.

• Security: Remember to secure the crap out of everything you do.  This is your bible.