Why is in-process session unacceptable, if it’s the fastest solution?
First, to use in-process sessions in a web farm, you must use some sort of server affinity load balancing technique, such as sticky sessions, to ensure that requests are routed to the servers with their session data. This actually reduces your application's availability, because if one server in your farm goes down it is guaranteed to affect all the users that were using that server. In addition, the need for server affinity reduces the efficiency of the load balancer.
Second, upgrading servers with new code (or even Windows updates) requires that a server being updated must be drained of all sessions which can take a very long time if there are a large number of active users on the server. That time is multiplied by at least 2 if updating half the servers at a time (and takes much more time if servers are updated one at a time). This can cause delays in getting updates out and waste time in the IT department.
Third, IIS recycles the ASP.NET worker process more often than people think. When recycling happens all in-process sessions are lost. It’s an uncontrollable process that is trigged by memory usage. The memory limit is 800MB on a 32bit machine regardless of physical RAM. By default IIS also recycles the worker process every 29 hours, but applications under heavy load will hit the memory limit much sooner.
Does it really make sense to build dedicated image servers with IIS? Why shouldn’t we cache everything?
On a busy site, partitioning data makes sense when practical. Image servers are a good example of a practical partioning of data and traffic. The partitioning is a good idea because it makes better use of memory. Each web application instance has a limited amount of memory resources available, and yet the more data that can be brought into cache, the faster the web server will respond. There is a delicate balance between how much memory is available for caching and how much is needed by processing threads to respond to client requests. Often this balance changes with a web application's usage patterns. Using the 32bit version of IIS 6 there is 750 MB threshold after which the garbage collection slows and the web application's worker process often re-cycles. When all resources used by an ASP.NET application are managed generically by all servers hosting the application each of the servers in the cluster can suffer from this problem. By creating a specialized server (or cluster) for images the IIS server is not forced to balance between memory for image caching and memory for client requests. Instead they are manage separately and more efficiency because the unwanted competition for memory resources has been removed.
Although this is a powerful technique sometimes it can be difficult to implement because all of the resource links in the content must be directed to the dedicated server. This may require a code change to correspond to the relocated resources.
What's the challenge with in-process session, if it’s the fastest solution?
First, to use in-process sessions in a web farm, you must use some sort of server affinity load balancing technique, such as sticky sessions, to ensure that requests are routed to the servers with their session data. This actually reduces your application's availability, because if one server in your farm goes down it is guaranteed to affect all the users that were using that server. In addition, the need for server affinity reduces the efficiency of the load balancer.
Second, upgrading servers with new code (or even Windows updates), requires that a server being updated must be drained of all sessions. This can take a very long time if there are a large number of active users on the server. That time is multiplied by at least 2 if updating half the servers at a time (and takes much more time if servers are updated one at a time). This can cause delays in getting updates out and waste time in the IT department.
Third, IIS recycles the ASP.NET worker process more often than people think. When recycling happens all in-process sessions are lost. It’s an uncontrollable process that is trigged by memory usage. The memory limit is 800MB on a 32bit machine regardless of physical RAM. By default IIS also recycles the worker process every 29 hours, but applications under heavy load will hit the memory limit much sooner.
Welcome to the Performance Blog
Starting long before we launched Strangeloop, we've
been engaged in many conversations about how to get the best performance from
ASP.NET applications. As we began to build the Strangeloop AS1000
and work closely with customers with ASP.NET applications, we have
encountered even more questions, spent hours researching and testing
answers, and engaged in debate over these answers.
We've created this blog to open these dialogues to more members of the ASP.NET
developer and IT community.
We'll post performance questions and issues along with our answers. We're
hoping you'll add your comments and pose questions.
Kent Alstad, Strangeloop CTO and the Office of the CTO Team
