All applications created to run for a potentially endless time are subject to the same big issue—memory leaks. It can be taken as a matter of fact that, on the average, all applications lose some bits of memory. This may not be a problem if the application runs for short sessions; it becomes a significant hurdle for applications that have to be up 24x7. ASP.NET applications just fall in this category. Aware of this statistic, designers of ASP.NET implemented a feature named "application restart" or process recycling. Simply put, application restarts are events in the lifetime of a deployed application that cause the worker process to kill the process and restart it. By killing the process, all cached information is lost, but at the same time any leaked memory is recovered. The worker process sets up an automatic system that periodically pings the application to ensure it is in health and restarts it if it detects the application is too slow in responding. There are a few reasons why an ASP.NET application can be restarted. Let's briefly review them.
The most common reason is that an application may get to consume more than a certain share of virtual memory. When this happens, the application is killed and restarted. The critical threshold of virtual memory is configurable and set to 60% by default. You should manage this parameter and ensure that it never exceeds the 800 MB value. You configure recycling through the Properties box of the Application Pool section of your IIS manager snap-in.
In addition, the ASP.NET runtime implements a good deal of checks and automatically restarts an application in a number of situations. For example, the application restarts after reaching the maximum limit of dynamic page compilations. Each time you edit source files, you generate a dynamic page compilation. At some point, the whole application is restarted because the number of loaded assemblies—one for each (re)created page—is too high. The application is recycled also if the physical path of the Web application changes, or any directory under the Web application folder is renamed. Any changes to global.asax, machine.config, or web.config in the application root, or in the Bin directory or any of its subdirectories, and changes occurring in the code-access security policy file, if one exists, are likewise situations that lead to a recycle.
Finally, if you edit the Properties box of the application and modify settings that control the restart/shutdown of the worker process, the application is restarted for the new settings to be applied. These settings are read from machine.config unless you use Windows Server 2003 with the IIS 6.0 process model. If you're taking full advantage of IIS 6.0, an application is restarted if you modify properties in the Application Pools node of the IIS manager. Note also that in addition to all this, in ASP.NET 2.0 an application can be restarted programmatically by calling the method UnloadAppDomain on the HttpRuntime object.
Application restarts are frequent in ASP.NET applications and developers and administrators should pay attention to keep their occurrences under control. When this happens, session state and cached data are lost. This might be a nasty thing for a Web site.
