我想知道究竟是什么工作进程回收？ 究竟它在工作进程回收时间？ 在工作进程驻留在应用程序池和可配置 通过应用程序池？ 是应用程序池负责 回收工作进程？或IIS负责回收呢？ 在什么时间回收工作进程会怎么样？ 在什么都没有迫使它的影响回收？ 解决方案

IIS工作进程回收是个过程，IIS杀害儿童的流程，它产生到处理传入的请求，并开始他们的干净的副本。

第一次IIS得到了在给定的应用程序池Web应用程序的请求时，它产生一个工作进程，以实际做的工作。这个过程不会像保持从你的ASP.NET code，ISAPI处理等会话状态和静态数据随着时间的推移，可能会出现的处理问题（在应用程序code内存泄漏，未予处置的资源，等等），IIS要清理，而不必关闭服务器。因此，它会定期告知工作进程死光了，并产生一个新的。

在循环周期来临时，IIS停止发送新的服务请求到死亡过程，并允许其完成任何它通常做的事情。这将产生提前一个新的，更换过程并开始发送新的请求到之一，而旧的结束了。一旦什么都不剩了老工艺做，正常终止。

工作进程被隔离到一个给定的应用程序池，因为这是IIS如何完成进程隔离。 （这就是为什么，例如，你可以混合使用的.NET Framework版本在单个服务器上 - 每个应用程序池都有自己的加载框架库与其他区分开来。）应用程序池决定有关工作进程的其他东西，包括他们的凭据多久的过程中保持周围被关闭了。

有真的不是一个很好的理由关掉回收利用，但如果一切正常，应该不会伤害任何东西。这些问题如果运行工作进程的行为不端之内code出现;随着时间的推移，即使微小的内存或资源泄漏积聚，你必须关闭应用程序池下清除它们。重叠的回收，IIS照顾，对你的服务不中断。

I would like to know what is exactly worker process recycling? What exactly it does at the time of worker process recycling? Worker process resides in application pool and can be configured through application pool? Is that application pool is responsible to recycle worker process? or IIS is responsible to recycle it? What happens at the time recycling worker process? 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.