在 Web 应用程序中使用工作线程或 ThreadPool 线程进行异步 I/O

Question

我推断，由于 ASP.NET Web 应用程序被授予固定数量的工作线程和 I/O 线程，这由 web.config 文件中的<processModel> 设置控制，因此，对于具有对于许多用户来说，旋转新的工作线程或使用 .NET 线程池中的线程来执行诸如记录错误或发送电子邮件等任务并没有特别的好处。

也就是说，假设在我的web应用中，对于每一个进来的请求，request handler连续执行3个任务，分别是Task A，接着是Task B，接着是Task C，然后返回结果，这是一个 HTML 页面。

但是，在这三个任务中，任务 B 与生成的 HTML 没有任何关系。这可能是一项任务，例如在日志文件中记录一段文本。

然后，如果我将任务 B 移动到另一个工作线程，而 CurrentThread（也是 ASP.NET 工作线程池中的一个工作线程）将更快返回，并为我的工作带来更好的响应时间应用程序的用户，我的应用程序可以服务的并发用户数将受到影响，因为任务 B 需要从同一个 ASP.NET 工作线程池分配新的工作线程。

因此，在 Web 应用程序场景中，我的理解是否正确：分叉新线程会对性能产生积极影响，但会对可伸缩性产生不利影响。因此，如果我们有幸通过购买大量硬件进行横向扩展，我们就必须编写多线程服务器端代码？

如果不是，那我们只是用一个换另一个？

Answer 1

您的问题的核心似乎是：“是否会使用其他线程异步处理次要关注点，阻碍我扩展垂直性能的能力？即每个 Web 服务器一次可以处理的连接数。"

通常不会有更多正在处理的请求，而不是线程数。 .Net 线程池中为每个虚拟 CPU 内核（逻辑处理器）分配了 100 个线程。您可以通过以下调用 ThreadPool.GetAvailableThreads Method 在您的机器上进行测试。

根据我的经验，简短的回答是“是”，但这仅在 Web 服务器的 CPU 是应用程序流量负载的瓶颈时才成立。因此，如果 Web 服务器正在等待数据库，或等待 API 调用返回，您可能会在 CPU 用尽之前将其他资源用尽。

在尝试扩展独立处理任务的处理时，推荐的解决方案是使用队列，例如Microsoft Message Queue 或RabbitMQ。然后，您可以根据需要在“服务”机器上单独分配尽可能多的线程来完成这些独立于请求的任务，同时最大限度地利用您的 Web 服务器资源。

使用队列进行离线处理也很容易扩展。当您还小的时候，您可以在同一个机器上运行所有这些服务，但当您需要更多处理能力时，您可以将该服务移至另一台机器或任意数量的机器上。

这个链接的question and answer有点相似。