Overlapped Recycling And SharePoint
I want to explain why it is important to configure IIS Application Pools running SharePoint to use the feature in IIS 6.0 called Overlapped Recycling. I think an effective way to do this is to parse the existing documentation on IIS Process Recycling and add some comments relative to SharePoint. Due to the fact that I have a lot to add to each of the topics covered in this documentation as well as adding a few topics of my own, I’ll be doing this as a series of posts instead of one huge post. Also, I will be covering the sections of the documentation out of order because I think it makes more sense for this discussion.
The beginning of the document discusses the differences between IIS 5.0 and IIS 6.0. Since SharePoint doesn’t run in IIS 5.0 isolation mode we won’t waste any time on that. The first part of that documentation that I want to elaborate on is the description of the two types of process recycling. It says:
Process recycling, which follows the occurrence of a recycling event, can happen in two ways.
If the worker process currently serving the application pool terminates, then the WWW Service (W3SVC), acting as the parent process to the worker processes, restarts a new process in its place.
When the worker process terminates, a new one is started simultaneously. This type of recycling is called overlapped recycling. It is the default for all application pools.
The difference between these two events from a user impact perspective is an important thing to understand. One has an obvious and negative impact on user experience and the other, when properly configured, goes by virtually unnoticed by the user.
The first kind, unexpected termination, results in all in-flight users request being dropped. The client will NOT have a good experience as a result of this. Most users who had in-flight requests will end up with some sort of page load failure. Some may get an HTTP 500 error, a page timeout error or some other ugly response.
The only bright spot in this type of recycle event is that as soon as the worker process terminates, IIS leaps into action by creating a new worker process. In most cases this is even less impactful than it sounds because all requests that come in while we are in this transition phase from one worker process to another are held in a queue in HTTP.SYS and will end up getting handled, albeit with a little delay, caused by the time it takes to instantiate a new worker process.
The second kind of recycling, overlapped recycling, is described fairly well by the documentation:
In an overlapped recycling scenario, the process targeted for a recycle continues to process all remaining requests while a replacement worker process is created simultaneously. The new process is started before the old worker process stops, and requests are then directed to the new process. This design prevents delays in service, since the old process continues to accept requests until the new process has initialized successfully, and is instructed to shut down only after the new process is ready to handle requests.
What this means is that when an overlapped recycle is required for whatever reason you will in effect have a pair of worker processes running simultaneously. The new one will get all the new requests that come in and the old one will finish serving the in-flight requests and then quietly go away. There are some caveats to this:
· If you do not properly configure the worker process shut down timeout value, some long running user requests, like large file uploads, may still get dropped. I will address configuring this value in a future post.
· You need to ensure that your server has enough free memory at all times to support the demands of the extra worker processes. The use of web gardening may make this a tricky proposition. I will discuss this in later posts.
Join me tomorrow for a post titled: Overlapped Recycling And SharePoint: The Basic Value Of Overlapped Recycling