0

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

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

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

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

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

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

4

1 回答 1

1

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

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

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

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

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

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

于 2013-04-17T21:36:41.483 回答