Scott Hanselman

Load Balancing and ASP.NET

March 23, 2004 Comment on this post [2] Posted in ASP.NET | ViewState
Sponsored By

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 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 ServerSome 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.


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


    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. 

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
March 24, 2004 8:24
You may take a look at this FAQ for Sessions too:
March 24, 2004 9:54
One other item to keep in mind is In-Process Session State + One Web Server on Windows 2003. With this you can have multiple worker processes (e.g. a web garden) which suffers from the same problem as In-Process + More than One Web Server as each process has its own session state and each time a user connects they may get routed to a different worker process and a different session state (our project found this out the hard way). Just something to be aware of.

Oh and another reason to always use Out-of-Proc (State Server) is that it will help you catch serialization problems. This will allow you to make sure you can choose which Session State you want to use because your development will be ready either way.

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.