Overlapped Recycling And SharePoint: Configuring The Shutdown Timeout
The previous post was so short, I though today I’d give you two posts. The shutdown timeout value is used to determine how long IIS will allow for the old worker process to finish the in-flight requests that were active at the time of the recycle event before it forcibly terminates the process and drops the request. To be very clear here, if the application pool competes all of its outstanding requests before the timeout expires then it will terminate at that time. If the timeout is hit before the requests are complete, IIS will forcibly terminate the worker process and the users will eventually receive a timeout error.
The default for the shut down timeout setting is 90 seconds. This seems like a long time for most web applications. However it may not be enough for a SharePoint Server. Consider this scenario; You have configured your server to allow file uploads of up to 50MB. You have users who telecommute and even some on other continents from time to time. These both represent an opportunity for very long running operations. When you throw these into the overlapped recycle scenario you will probably end up exceeding that 90 second timeout value by a wide margin.
This is why you need to carefully configure the shut down timeout when using overlapped recycling. Setting it too low results in intentionally dropping user requests which is very harmful the user experience. Setting this value too high results in a worker process that could potentially hang around too long.
How long is too long? Depending on how tight you are on free physical memory you could end up impacting overall server performance by keeping this large worker process around while other demands for server memory cause you to start paging. Assuming you have followed the memory guidance from the previous post, Overlapped Recycling And SharePoint: What To Watch Out For, then you are probably relatively safe from this problem. That really only leaves the user impact to be considered.
In our documentation we recommend that you set this value at 300 seconds. This is probably going to meet the needs of most environments. The way to know if you haven’t allowed enough time for all the longer running requests to complete is to monitor the Application Event Log. If you see warning event messages like the one below then you may want increase the timeout further:
|
Event Type: Warning
Event Source: W3SVC
Event Category: None
Event ID: 1013
Date: 12/1/2007
Time: 13:07:21 PM
User: N/A
Computer: <ComputerName>
Description: A process serving application pool 'SharePoint - 80' exceeded time limits during shut down. The process id was '<xxxx>'.
|
In the end, it is entirely up to you how long you are willing to have that extra worker process hanging around.
Stop back by tomorro when I will give you my thoughts on: Overlapped Recycling And SharePoint: What Are The 64-bit Settings?
