Recycling Worker Processes (IIS 6.0)
If an application contains code that causes problems, and you cannot easily rewrite the code, it might be useful to limit the extent of the problems by periodically recycling the worker process that services the application. Worker process recycling is the replacing of the instance of the application in memory. IIS 6.0 can automatically recycle worker processes by restarting the worker process, or worker processes, that are assigned to an application pool. This helps keep problematic applications running smoothly, and minimizes problems such as memory leaks.
You can trigger the recycling of the worker processes assigned to an application pool by using worker process recycling methods that are based on elapsed time, the number of Hypertext Transfer Protocol (HTTP) requests, a set time of day, and two kinds of memory consumption, in addition to recycling on demand. Table 4.1 lists and describes the worker process recycling methods and when to use each.
By setting the values for worker process recycling methods, you can schedule recycling events to manage application problems in a timely manner. Table 4.2 lists recommendations for adjusting the values of worker process recycling methods.
Recycling and Maintaining State
If you have an application pool with applications that depend on state data, you must decide whether or not to recycle the worker processes that are assigned to that application pool. When you recycle a worker process, the state data for applications that is maintained in process is lost. In this case, do not use recycling.
One alternative to increasing application availability by recycling worker processes is to maintain state data external to the worker process, such as in a database. However, moving data to an external database to allow recycling can affect server performance in the following two ways:
ASP.NET gives you the option of persisting session state using a session state service or a SQL database. For more information on deploying ASP.NET applications, see Deploying ASP.NET Applications in IIS 6.0.
Global Locks and Overlapped Recycling
Using global locks, configuring files for exclusive read, and other methods of exclusive resource ownership prevent the use of overlapped recycling, or the loading of an application in two application pools simultaneously. Exclusive ownership requires the use of non-overlapped recycling and the routing of all requests for that application to the same application pool. Also, you can run only one worker process for that application pool, which means that exclusive ownership does not work in a Web garden. One way to work around this is to write multithreaded applications, or use shared reads, which might eliminate the need for exclusively owned resources.