What is worker process recycling....?

开发者_如何学Go
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?

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.

Worker process recycling just means the restart of the asp .net worker process (aspnet_wp.exe) . It's done due to various reasons. The following article describes things quite decently. http://technet.microsoft.com/en-us/library/cc759005(WS.10).aspx

Please go through it.

Scenarios vary, but just to keep in mind: If your web app does initial in-memory caching of db information (let's say huge initial caching), the first request to the newly spawned apppool will take long to complete.