I've been teaching the IIS training course offered by Accelebrate for quite some time. Of all the questions I've received from students, the greatest percentage of them involve some aspect of recycling. What can cause a recycle to happen? What are the effects on my application when a recycle occurs? Should I completely turn it off if possible? In this article, my aim is to present a concise description of application pool recycling in IIS and address many of the common questions I've been asked over the years.
This article is written with IIS 7 and 7.5 in mind. Some information may not apply to earlier or later versions of IIS.
Application domain recycle vs. application pool recycle
The first item I want to address is the confusion that sometimes exists between the recycle of an application domain and the recycle of an application pool. There are cases where an application domain must be unloaded from memory, reloaded, and the code re-jitted. This process does not terminate the worker process (w3wp.exe) and therefore does not affect other application domains assigned to the same pool. There are other circumstances that require an application pool to recycle and therefore cause all application domains assigned to the pool to be reloaded.
I should mention at this point that the generally accepted best practice is to assign each application to its own pool.
Causes of an application domain recycle
The following circumstances will cause a recycle of an application domain:
- Modification to web.config or Global.asax
- Change to the contents of the application's bin directory
- Change to the physical path of the virtual directory
- Deletion of the subdirectory of the application
- The number of re-compilations (aspx, ascx or asax) exceeds the limit specified by the <compilation numRecompilesBeforeAppRestart=/> setting in machine.config or web.config (default of 15)
Notice the last item in the above list. ASP.NET does allow for the dynamic recompilation of resources without having to restart the application domain. This is why it is possible, for example, to modify an aspx page on a live server without the effect of losing active session and cache data. The capability is limited to a specific number of recompiles due to the inability of .NET to remove code from a running application domain (only add). If set to a higher value, the memory footprint of the application domain would necessarily increase over time and could eventually have adverse effects.
For some great information on tracking down the cause of unintended application domain recycles, take a look at this blog post by Tess Ferrandez.
Effects of an application domain recycle
The effects of an application domain recycle include:
- Performance hit with all of the assemblies being reloaded and re-jitted.
- Loss of all in-process variables (session, application, and cache). This issue can be mostly eliminated through the use of out-of-processes session state (ie. StateServer) and cache mechanisms (ie. AppFabric)
There are some issues that may occur when making multiple changes (that require a recycle) to an application while the application is receiving requests. In this situation, you may end up with multiple recycles occurring (triggered by the incoming requests) and some of those requests may be served by the application in a "partially updated" state. Also, multiple simultaneous reloads may trigger a "file in use" error. The best approach here is to try and avoid this situation (updates while under load). However, if needed, a possible solution is available here: http://support.microsoft.com/kb/810281
Causes of an application pool recycle
An application pool recycle is when the all of the worker processes (w3wp.exe) for an application pool are unloaded and new instances are started to serve incoming requests.
By default, each application pool uses a single worker process. However, it is possible to configure an application pool to use more then one worker process thereby creating what is known as a "web garden".
Circumstances that can cause an application pool recycle to occur:
-
Configuring a recycling condition for the pool
- Regular time interval (default of 1740 minutes)
- Fixed number of requests
- Specific time
- Virtual memory usage
- Private memory usage
- Having a idle time-out value set for the pool (default of 20 minutes)
- Making a configuration change in IIS that causes a recycle
The recycling conditions are there for your convenience but you should think carefully before using them. We will talk more about that in a moment. For now, just take note of the default value (1740 minutes). Also notice that even if you disable all of the recycling conditions, the application pool will still recycle if idle for 20 minutes. This is especially important if you decide to set your application’s session timeout to a value greater than the default of 20 minutes.
Regarding configuration changes in IIS that cause the pool to recycle, it is somewhat difficult to pin down exactly what changes will or will not cause a recycle. Visit this blog post for more information on that issue. What you should know thought is that you can disable this behavior completely by setting the “Disable Recycling for Configuration Changes” property to True in the Advanced Settings for the application pool. Just keep in mind that any changes made potentially will not be in effect until you manually recycle the pool.
Overlapped recycle of application pools
If an application pool does recycle, it does so (by default) using a technique called “overlapped recycle”. When an application pool recycle event occurs, the first step taken by IIS is to launch the a worker process (or multiple processes in the case of a web garden). Once the new worker process is able to process requests, the old worker process is shutdown. This mitigates the potential performance impact of a recycle and ensures a process is always available to service requests. Many options exist for customizing this process including time limits for process startup/shutdown. Overlapped recycle can also be disabled entirely.
Effects of an application pool recycle
As with an application domain recycle, all in-process variables (session, application, and cache) are lost. Depending on your application and the recycling conditions that are in effect, this may represent justification for investigating out-of-process options for session state and caching.
Is automatic application pool recycling necessary?
This is one of the most popular questions I'm asked and one that is a little tricky to answer. Basically, the answer is that is should not be. However, in many cases, it may be (at least temporarily). Every case I have encountered where application pool recycling was necessary was to deal with an application that would leak memory over time. Most ASP.NET developers immediately respond with "This is .NET. We have a garbage collector. How is that possible?" Well, there are cases where it can happen if you're not careful. Here is a blog post I came across that describes one such example. It is always possible to fix these types of issues but application pool recycling may be your best option until such action can be taken.
comments powered by Disqus