IIS 工作线程与 Web 应用程序线程答案

【问题标题】：IIS worker thread vs web application threadIIS 工作线程与 Web 应用程序线程
【发布时间】：2020-08-28 13:59:15
【问题描述】：

我正在维护一个需要重复运行一些后台线程的ASP.NET Core Web 应用程序。我知道这不是一个好的设计，但目前我必须以最小的努力解决它的主要问题。现在我想知道我是否应该担心Web服务器处理用户的http请求？

问题很简单，但我找不到任何明确的答案：

这样在应用程序中创建的线程有什么区别：

Task.Run(() => { // some parallel job })

以及处理 http 请求的 IIS 工作线程？

它们是来自同一个线程池还是位于不同的池中？

【问题讨论】：

Web 服务器旨在接受请求、处理并快速返回，不应用于“密集型”代码。 IMO 这些工作任务应该在不同的（非网络）服务器上运行，这样它们就不会干扰提供网页的工作。
@Neil 你完全正确，但问题的焦点更多地在于两种线程之间的差异以及它们之间的关系和相互影响
它们基本相同。但是您不应该在 Web 服务器应用程序上执行此操作。每次这样做都会影响性能和可用性。
@PauloMorgado 我同意这不是一个好的设计，这个系统是几年前设计的，目前我必须以最小的努力解决它的问题。您能否更详细地解释 iis 线程和应用程序线程的关系？如果它们相同，我会感到困惑的是，它们如何与托管应用程序域和非托管 http 请求上下文进行交互！
一般来说，如果你在网络服务器上使用Task.Run，那是因为你正在做一些不应该做的事情来处理网络请求。如果您在此之上阻止当前线程，那么您将无法获得双倍成本。处理请求的线程、处理 I/O 回调的线程、运行异步延续的线程和Task.Run 都使用来自同一个线程池的线程。如果浪费它们，会使整个应用程序变慢，甚至可能导致死锁。

【解决方案1】：

根据this，它是一个池：“ASP.NET Core 已经在普通线程池线程上运行应用程序代码。”换句话说，服务请求的线程与后台线程没有单独的最大值。

最大的区别是 IIS 知道它自己为传入请求创建的线程。 IIS 不知道您自己创建的任何线程。

当应用程序池被回收或 IIS 关闭时，它会一直等待，直到所有请求都完成处理——它会等待它为每个请求创建的线程完成处理——然后它会终止进程。如果您创建的任何线程超过了请求（例如，如果您创建了一个后台线程，然后将响应发送回客户端），IIS 不知道该线程仍在运行，并且可能随时终止整个进程。

如果您在所有线程都完成之前不返回响应，那么您将不会遇到该特定问题。

另一个问题是您可能会达到允许的最大线程数。然后会发生各种奇怪的性能问题。但这取决于您创建的线程数以及传入的 HTTP 请求数。

【讨论】：

感谢 Gabriel 的回答，所以您说这两种类型的线程都存在于共同的 Thread Pool 中，对吗？我们可以为 IIS 工作线程和应用程序后台线程单独设置任何最大数量限制，以防止它们相互爆炸吗？！
您标记了 ASP.NET Core。您使用的是 Core 还是只是普通的 ASP.NET？它还可能取决于您是否在进程中运行 Core 应用程序。
它是ASP.NET Core。目前它的主机为In-Process，但如果你也能解释这与Out of Process的区别，我将不胜感激
根据this 的说法，这都是一个池：“ASP.NET Core 已经在普通线程池线程上运行应用程序代码。”换句话说，服务请求的线程与后台线程没有单独的最大值。