ASP.NET and Web Gardens
When you are running your ASP.NET applications inside an application pool with only 1 worker process, everything works as expected. But things usually do not go so smoothly when you run the same application inside a web garden.
What is a web garden
Simply put, a web garden is a single web server running multiple IIS processes. The good thing about this is, there are multiple process which can service your http/https calls. So if a client is holding up one process, the other processes can still continue. Also if a particular process were to hang and restart itself, your website will still continue to serve clients as the other processes are running.
Read more about Microsoft’s explanation of web garden here
The article clearly states that
all processes have their own copy of application state, in-process session state, caches, and static data
Let us examine each one of these and see what we can do to workaround it
As each process has their own application state, whatever you change in one process will not be updated in another process. As this exists purely for backward compatibility with classic ASP applicationstate, Microsoft does not recommend using this alot, especially for read/write operations.
Use Cache instead of ApplicationState if you can.
Be it HttpRunTime.Cache or Enterprise Library Cache, the cache will not reflect latest updates inside a web garden. This is because only the worker process which updated the Cache Item will see the updated values, the other worker processes will not be notified that a change has happened and will continue using the value stored in their in memory cache.
There are a few paid solutions, and the only free one so far which is able to address this is can be found at http://enyimmemcached.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=13095 or http://www.codeproject.com/KB/aspnet/memcached_aspnet.asp
Using web gardens, you will find that the session values gets rotated around. Again this is due to the fact that different worker process is handling your request, and each worker process has its own session state management.
Simply change the inproc to either State Server or SQL Server to store the session state outside of the worker process. Performance will degrade when using either of these 2 options, but at least you can be assured of the persistancy of the data