IIS在通用工作进程中运行所有Web应用程序 – w3wp.exe.无论您是在ASP.NET,ISAPI还是其他框架中编写,为Web请求提供服务的过程都是w3wp.exe.在ASP.NET的情况下,w3wp.exe加载ASP.NET JIT编译的DLL并通过它们为请求提供服务.在其他情况下,它的工作方式不同.但关键的一点是,w3wp.exe就是这个过程.此模型在IIS6.0中启动,并在IIS7.0中继续.

意外失败

如果W3WP.exe因任何原因意外失败,它正在处理的所有事务都可能会出现500个错误(服务器错误). IIS将在其位置(MS calls this “Health Monitoring”)启动新的工作进程,这意味着Web应用程序将继续运行.在失败时没有由失败进程提供服务请求的用户将不会意识到这一点.

The HTTP 500 error that a client receives in this case will be indistinguishable from a 500 error that the client receives in the case of an application error,let’s say an uncaught exception in your ASPNET application code.

对于那些处于失败过程中的请求,没有办法恢复它们.它们将导致浏览器出现500错误.由于连接数量的阈值,IIS主动拒绝连接导致503 Server Busy结果. 503不是由应用程序故障引起的,因此您不应期望在内存和崩溃情况下看到503用于正在进行的事务.在负载很重的系统上,您可能会看到503作为进程崩溃和重启发生,作为次要影响.如果这正是您所看到的,则需要更大的安全裕度来处理单错误情况下的负载.

请求队列

当它们到达网络层(Http.sys)时,它们被放置在队列中,由工作进程拾取.在IIS队列中等待由WP处理的任何请求将继续不受影响,但由于资源争用,它们可能会看到延迟(服务时间)略有暂时增加,因为服务器上正在运行的进程少一个.在正确配置的系统上,此队列中的等待时间通常非常短.

当此队列已满时,您将看到503错误.

自动重启W3WP.exe

IIS具有自动重启(或“保姆”)工具,it restarts worker processes after they have exceeded configured thresholds通过该工具,例如内存大小,请求数或运行时间.在所有这些情况下,IIS将在达到配置的阈值时停顿并重新启动工作进程.这些主动重启通常不会导致请求中断.当IIS确定需要重新启动工作进程时,它会阻止任何新请求到达该待静止WP. Existing requests are drained：允许该WP中的任何正在进行的交易正常完成.当WP中的所有请求完成后,WP就会死掉,IIS会在其位置启动一个新的请求.然后,这个新进程立即开始从调度队列中获取新请求.这对用户或浏览器都是透明的.

我通常说是因为工作流程可能在达到阈值的同时变得真正生病.在这种情况下,w3wp.exe可能无法在the configured “quiesce” timeout内响应IIS,因此IIS必须最终终止该进程,即使它尚未报告其所有正在进行的请求已完成.这应该是非常罕见的,因为它是两个截然不同的特殊情况,但它会发生.在这种情况下,飞行中的请求将再次获得500个错误.

网络花园

此外 – IIS允许单个服务器上的多个工作进程. MS calls this a “web garden”,播放“网络农场”中的文字.如果您设置了Web园,那么除了失败的w3wp.exe实例所服务的事务将继续不受影响.但是,“未受影响”假定内存不足错误是本地化的,而不是系统范围的问题.

底线

最重要的是,您自己的测试无可替代.配置选项非常广泛 – 从重启阈值到网络花园等等.此外,失败模式往往非常复杂和多变,无论是内存,超时,太忙,等等.你会想知道会发生什么.

ps：这个Q& A真的属于serverfault.com !!

引用：
http://blogs.iis.net/thomad/archive/2008/05/07/the-iis-process-model-features.aspx