我推断，因为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应用程序场景中：分叉新线程会对性能产生积极影响，但会对可伸缩性产生负面影响。因此，如果我们通过购买大量硬件进行扩展，我们必须编写多线程服务器端代码？
如果没有，那么我们只为另一方换掉一个？
答案 0 :(得分：1)
您的问题的核心似乎是：“将使用其他线程异步处理次要问题，阻碍我扩展垂直性能的能力？即每个Web服务器可以同时处理的连接数。“
与线程相比，通常不会有更多的请求被主动处理。每个虚拟CPU核心（逻辑处理器）为.Net线程池分配了100个线程。您可以使用以下呼叫ThreadPool.GetAvailableThreads Method在您的计算机上对此进行测试。
根据我的经验，简短的回答是“是”，但只有当Web服务器的CPU是应用程序流量负载的瓶颈时才会出现这种情况。因此，如果Web服务器正在等待数据库，或者等待API调用返回，则可以在最大化CPU之前最大化其他资源。
尝试扩展独立处理任务的处理时，建议的解决方案是使用队列，例如Microsoft Message Queue或RabbitMQ 。然后，您可以根据需要在“服务”计算机上单独分配多个线程来完成这些请求独立任务，同时最大限度地利用您的Web服务器资源。
使用队列进行离线处理也很容易扩展。当你很小时，你可以在同一个盒子上运行所有这些服务，但当你到达需要更多处理能力的点时，你可以将该服务移动到另一台机器或根据需要的多台机器。
此链接的question and answer有点类似。