我们有一个处理大量请求的WCF服务。
正如我所发现的那样，当cuncurrent请求的数量超过max cuncurrent连接的限制时，随后的请求将被排队等待稍后执行。 如果在这些请求有机会执行之前发生超时，IIS将无响应地确定工作进程并杀死它（或者回收应用程序池）。
回收过程大概需要一分钟，同时服务也会下降，这对我们来说是个大问题。
无论代码中的超时和响应时间长是什么原因（我们已经在处理它），我的问题是：
如果我们为这个应用程序池定义多个工作进程，如果其中一个工作进程处于相同的情况，会发生什么情况？ IIS是否回收应用程序池或特定的工作进程将被杀害，其他人继续为请求提供服务？
如果真的需要工作进程来解决这个问题，那么可以禁用高级应用程序池属性中的Pingfunction，这就是我假设IIS检测到App Pool已经无响应的情况。
你可能想要确定你的工作进程将会恢复，但是，基于Ping的回收是安全带，这意味着如果站点挂起，你不需要在凌晨2点起床。
如果工作进程主动向IIS报告自己的失败，那么从IIS的angular度来看，这可能是不可避免的，您需要禁用应用程序框架自身的健康报告function。
在上面的另一个问题/替代scheme中：如果您的应用程序是无状态的，并且支持在Web Garden中进行多实例化（MaxProcesses> 1），那么IIS将回收已经无响应的工作进程，而不是属于应用程序池的所有WP – 查找识别被回收的PID的系统事件日志。