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

Question

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

换句话说，假设在我的Web应用程序中，对于传入的每个请求，请求处理程序将连续执行3个任务，即任务A，任务B，任务C，然后返回结果，即HTML页面。

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

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

因此，我理解在Web应用程序场景中是正确的：派生新线程将对性能产生积极影响，但对可伸缩性产生不利影响。 因此，如果我们有足够的能力通过购买大量硬件进行扩展，那么我们只能编写多线程服务器端代码？

如果没有，那么我们只是权衡取舍？

Answer 1

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

通常，正在处理的请求最多只能有线程。 .Net线程池中为每个虚拟CPU内核（逻辑处理器）分配了100个线程。 您可以使用以下调用ThreadPool.GetAvailableThreads方法在计算机上对此进行测试。

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

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

使用队列进行脱机处理也很容易扩展。 当您规模较小时，可以在同一个盒子上运行所有这些服务，但是当您需要更多处理能力时，可以将该服务移动到另一台计算机或所需的多台计算机。

这个链接的问题和答案有些相似。