我对ASP.Net工作进程如何处理进程的了解非常不足。我希望那里的一些专家可以填补我。
如果我使用System.OutOfMemoryException使工作进程崩溃，那么用户体验的是同一进程所服务的其他用户？他们会得到一个空白的屏幕吗？ 503错误？
我将尝试与我们实验室中的其他人一起测试这种情况，但我想我会把它漂浮在那里。我会用我们的结果更新。
更新：我们的结果各不相同。如果我们人为地引发OOM异常（例如通过将更大和更大的PDF加载到内存中），那个工作进程所服务的其他线程将暂时“挂起”然后完成，而其他线程似乎永远不会返回。谢谢你的回复。
答案 0 :(得分：9)
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应用程序将继续运行。在失败时没有由失败进程提供服务请求的用户将不会意识到这一点。
在这种情况下，客户端收到的HTTP 500错误与客户端在应用程序错误情况下收到的500错误无法区分，假设您的ASPNET应用程序代码中有未捕获的异常。
对于那些处于失败过程中的请求，无法恢复它们。它们将导致浏览器出现500错误。由于连接数量的阈值，IIS主动拒绝连接导致503 Server Busy结果。 503不是由应用程序故障引起的，因此您不应期望在内存和崩溃情况下看到503用于正在进行的事务。在负载很重的系统上，您可能会看到503作为进程崩溃和重启发生，作为次要影响。如果这正是您所看到的，则需要更大的安全裕度来处理单错误情况下的负载。
IIS has a hand-off approach for requests。当它们到达网络层（Http.sys）时，它们被放置在队列中，由工作进程拾取。在IIS队列中等待由WP处理的任何请求将继续不受影响，但由于资源争用，它们可能会看到延迟（服务时间）略有暂时增加，因为服务器上正在运行的进程少一个。在正确配置的系统上，此队列中的等待时间通常非常短。
当此队列已满时，您将看到503错误。
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＆amp; A真的属于serverfault.com !!
的引用：
http://blogs.iis.net/thomad/archive/2008/05/07/the-iis-process-model-features.aspx
答案 1 :(得分：0)
将启动一个新的工作线程，用户不会知道发生了什么。除非它通过快速失败（http://technet.microsoft.com/en-us/library/cc779127(WS.10).aspx）
完全关闭答案 2 :(得分：0)
如果是内存不足的情况，我通常会回收应用池。
答案 3 :(得分：0)
正如其他答案所说，在大多数情况下，一切都只是重新开始，大多数当时没有待处理请求的用户不会注意到延迟。
但是，如果您的应用程序使用具有In-Proc会话状态的会话变量，则当应用程序池重新启动时，所有用户的所有会话变量都将丢失。这可能会也可能不会对用户产生负面影响，具体取决于您对会话变量的处理方式。您可以通过切换到StateServer或SQL Server会话存储来避免这种情况。