IIS 上下文中的线程池答案

【问题标题】：Threadpool in IIS contextIIS 上下文中的线程池
【发布时间】：2010-11-30 00:15:51
【问题描述】：

在 IIS 上的 Web 应用程序中运行时，我有一个关于 System.Threading.Threadpool 的一般性问题。假设我们有 2 个请求同时执行，我们通过 ThreadPool.QueueUserWorkItem 方法启动了几个线程。两个请求会共享 ThreadPool，还是两个请求对 ThreadPool 的调用会在两个单独的池中运行？

这是在 IIS6 和 7 中。

感谢您的任何见解。

【问题讨论】：

标签： multithreading iis queue threadpool

【解决方案1】：

这是 MSDN 文档中关于 ThreadPool class 的引用：

每个进程有一个线程池。线程池的默认大小为每个可用 250 个工作线程处理器和 1000 I/O 完成线程。

在 IIS6 和 IIS7 中，任何给定的 ASP.NET 应用程序都通过应用程序池基础结构托管在单个进程 (w3wp.exe) 中。
一个应用程序池可以通过以下方式托管多个 Web 应用程序将它们保存在不同的 AppDomain 中，但它在服务器上的一个物理进程内运行。

这两个事实实际上意味着来自正在运行的 Web 应用程序实例的所有线程都在同一个 .NET 线程池中执行。

【讨论】：

所以这基本上意味着对于需要将任务触发到多个线程的 Web 应用程序使用 ThreadPool 是一个坏主意。
由于所有 Web 请求都已经异步处理，我想说在大多数情况下，您不会从在 Web 应用程序的后台线程中运行操作获得任何显着的好处。如果您不希望阻止处理请求以等待长时间运行的操作，则可能是一个例外。在这种情况下，您可以触发一个后台线程，对请求做更多的工作，然后最终等待它完成，然后再将响应发送给客户端。
就我而言，我有一个在 IIS 上下文中运行的服务，它向不同的搜索引擎发出 X 个传出请求。这些应该在几个线程中完成，因为我想在这里最大化速度。当所有线程都完成后，我将结果收集到一个结果列表中并将其返回给调用者。在这种情况下使用池的原因只是为了使用更少的内存，因为它重用了池中的线程。但是如果我使用与 IIS 相同的池，那么这可能不是一个好用的类。
嗯，在您的情况下，使用后台线程非常有意义，因为您希望并行执行多个操作。通常，出于您提到的原因，使用线程池而不是手动手动创建线程是一个好主意。如果您的站点没有处理大量流量，线程池可能可以满足所有请求而不会挨饿。但是，最好让您的 Web 应用程序在自己的应用程序池中运行，以确保它不必与其他人共享线程池。
@RoyiNamir 哪个部分过时了？