Question

1. I would like to know what is exactly worker process recycling?
2. What exactly it does at the time of worker process recycling?
3. Worker process resides in application pool and can be configured
   through application pool?
4. Is that application pool is responsible
   to recycle worker process? or IIS is responsible to recycle it?
5. What happens at the time recycling worker process?
6. What are the impact of not forcing it to recycle?

Answer 1

IIS Worker Process Recycling is the process whereby IIS kills of the child processes that it spawns to handle incoming requests and starts clean copies of them.

The first time IIS gets a request for a web application in a given application pool, it spawns a worker process to actually do the work. This process does things like maintaining the session state and static data from your ASP.NET code, ISAPI handlers, etc. Over time, problems could arise in the processing (memory leaks in the application code, undisposed resources, etc.) that IIS wants to clean up without having to shut down the server. So it will periodically tell the worker process to die off, and spawn a new one.

When the recycle period comes around, IIS stops sending new service requests to the dying process and allows it to finish whatever it’s doing normally. It will spawn a new, replacement process in advance and start sending new requests to that one while the old one finishes up. Once there’s nothing left for the old process to do, it terminates normally.

Worker processes are isolated to a given application pool, because that’s how IIS accomplishes process isolation. (This is why, for example, you can mix .NET Framework versions on a single server — each app pool gets its own loaded Framework libraries separate from the others.) The app pool determines other things about the worker processes, including their credentials and how long the process stays around before being shut down.

There’s really not a good reason to turn off recycling, but if everything is working properly it shouldn’t hurt anything. The problems arise if you run code within the worker process that misbehaves; over time even tiny memory or resource leaks build up and you have to shut down application pool down to clean them up. With overlapped recycling, IIS takes care of that for you with no disruption in service.