在高流量场景中使用 ASP.NET 中的 ThreadPool.QueueUserWorkItem

Question

我一直认为，即使在 ASP.NET 中，使用 ThreadPool 执行（比方说非关键的）短期后台任务也被认为是最佳实践，但后来我遇到了 这篇文章似乎另有暗示 - 论点是您应该让 ThreadPool 来处理 ASP.NET 相关请求。

因此，到目前为止，我一直在执行小型异步任务：

ThreadPool.QueueUserWorkItem(s => PostLog(logEvent))

文章建议改为显式创建线程，类似于：

new Thread(() => PostLog(logEvent)){ IsBackground = true }.Start()

第一种方法具有受管理和限制的优点，但有潜力（如果文章正确）然后后台任务会与 ASP.NET 请求处理程序争夺线程。第二种方法释放线程池，但代价是不受限制，因此可能会占用太多资源。

所以我的问题是，文章中的建议正确吗？

如果您的网站流量如此之大，以至于您的线程池已满，那么最好采用带外，还是满的线程池意味着您已经达到了资源的限制，在这种情况下，您不应该尝试启动自己的线程吗？

澄清：我只是在小型非关键异步任务（例如远程日志记录）的范围内询问，而不是需要单独流程的昂贵工作项目（在这些情况下，我同意您需要更强大的解决方案）。

Answer 1

这里的其他答案似乎遗漏了最重要的一点：

除非您尝试并行化 CPU 密集型操作以便在低负载站点上更快地完成它，否则使用工作线程是没有意义的

这适用于由 new Thread(...) 创建的自由线程，以及 ThreadPool 中响应 的工作线程QueueUserWorkItem 请求。

是的，确实如此，您可以通过对太多工作项进行排队来使 ASP.NET 进程中的 ThreadPool 挨饿。它将阻止 ASP.NET 处理进一步的请求。文章中的信息在这方面是准确的；用于 QueueUserWorkItem 的同一线程池也用于处理请求。

但是，如果您实际上排队的工作项足以导致这种饥饿，那么您应该使线程池饥饿！如果您同时运行数百个 CPU 密集型操作，那么当计算机已经过载时，使用另一个工作线程来处理 ASP.NET 请求有什么好处呢？如果您遇到这种情况，您需要彻底重新设计！

大多数时候，我看到或听说在 ASP.NET 中不恰当地使用多线程代码，它并不是为了对 CPU 密集型工作进行排队。它用于对 I/O 密集型工作进行排队。 如果您想要执行 I/O 工作，那么您应该使用 I/O 线程（I/O 完成端口）。

具体来说，您应该使用任何库类支持的异步回调你正在使用。这些方法总是有非常清晰的标签；它们以 Begin 和 End 一词开头。如Stream.BeginRead、Socket.BeginConnect、WebRequest.BeginGetResponse等。

这些方法确实使用ThreadPool，但它们使用IOCP，而IOCP不会干扰 ASP.NET 请求。它们是一种特殊的轻量级线程，可以被来自 I/O 系统的中断信号“唤醒”。在 ASP.NET 应用程序中，通常每个工作线程都有一个 I/O 线程，因此每个请求都可以有一个排队的异步操作。这实际上是数百个异步操作，而没有任何显着的性能下降（假设 I/O 子系统可以跟上）。它比您所需要的要多得多。

请记住，异步委托不会以这种方式工作 - 它们最终会使用工作线程，就像ThreadPool.QueueUserWorkItem一样。只有 .NET Framework 库类的内置异步方法才能够执行此操作。您可以自己做，但它很复杂，而且有点危险，可能超出了本讨论的范围。

在我看来，这个问题的最佳答案是不要在 ASP 中使用ThreadPool或后台Thread实例。 NET。它与在 Windows 窗体应用程序中旋转线程完全不同，在 Windows 窗体应用程序中，您这样做是为了保持 UI 响应，而不关心它的效率如何。在 ASP.NET 中，您关心的是吞吐量，无论您是否使用 ThreadPool<，所有这些工作线程上的所有上下文切换都绝对会杀死您的吞吐量/code> 或不。

如果您发现自己在 ASP.NET 中编写线程代码，请考虑是否可以重写它以使用预先存在的异步方法，如果不能，请考虑您是否真的需要该代码完全在后台线程中运行。在大多数情况下，您可能会增加复杂性而没有任何净收益。

Answer 2

根据 Microsoft ASP.NET 团队的 Thomas Marquadt 的说法，使用 ASP.NET ThreadPool (QueueUserWorkItem) 是安全的。

摘自文章：

问）如果我的 ASP.NET 应用程序使用 CLR ThreadPool 线程，我是否会耗尽 ASP.NET（它也使用 CLR ThreadPool 来执行请求）？
..

<块引用>

A）总而言之，不用担心
ASP.NET 线程匮乏，如果
你认为这里有问题让
我知道，我们会处理的。

问）我应该创建自己的线程吗
（新话题）？这不是更好吗
对于 ASP.NET，因为它使用 CLR
线程池。

<块引用>

A）请不要。或者把它放在一个
不同的方式，不！如果你真的
聪明——比我聪明得多——然后你
可以创建自己的线程；
否则，想都别想。
以下是您应该这样做的一些原因
不频繁创建新线程：

1. 与相比，它非常昂贵
   QueueUserWorkItem...顺便说一句，如果您可以编写比 CLR 更好的 ThreadPool，我鼓励您申请 Microsoft 的工作，因为我们肯定正在寻找像您这样的人！

Answer 3

网站不应该绕过生成线程。

您通常会将此功能移至 Windows 服务中，然后与之通信（我使用 MSMQ 与它们通信）。

-- 编辑

我在这里描述了一个实现： 基于队列ASP.NET MVC Web 应用程序中的后台处理

- 编辑

要详细说明为什么这比线程更好：

使用 MSMQ，您可以与另一台服务器进行通信。您可以跨机器写入队列，因此，如果您出于某种原因确定后台任务过多地消耗了主服务器的资源，您只需简单地转移它即可。

它还允许您批量处理您尝试执行的任何任务（发送电子邮件/其他内容）。

Answer 4

我绝对认为 ASP.NET 中快速、低优先级异步工作的一般做法是使用 .NET 线程池，特别是对于高流量场景，因为您希望资源受到限制。

此外，线程的实现是隐藏的 - 如果您开始生成自己的线程，则还必须正确管理它们。并不是说你做不到，但为什么要重新发明那个轮子呢？

如果性能成为问题，并且您可以确定线程池是限制因素（而不是数据库连接、传出网络连接、内存、页面超时等），那么您可以调整线程池配置以允许更多工作线程、更高的排队请求等等。

如果您没有性能问题，那么选择生成新线程以减少与 ASP.NET 请求队列的争用是典型的过早优化。

理想情况下，您不需要使用单独的线程来执行日志记录操作 - 只需使原始线程尽快完成操作，这就是 MSMQ 和单独的消费者线程/进程发挥作用的地方。我同意，这需要实现的工作量更大、工作量更大，但这里确实需要持久性 - 共享内存队列的波动性很快就会失去其受欢迎程度。

Answer 5

您应该使用 QueueUserWorkItem，并避免创建新线程，就像避免瘟疫一样。为了解释为什么您不会挨饿 ASP.NET，因为它使用相同的线程池，请想象一个非常熟练的杂耍演员用两只手保持六个保龄球瓶、剑或其他东西在飞行。为了直观地了解为什么创建自己的线程是不好的，想象一下在西雅图的高峰时段会发生什么，当时大量使用的高速公路入口坡道允许车辆立即进入交通，而不是使用交通灯并将入口数量限制为每隔几秒一个。最后，详细解释请参见此链接：

http://blogs.msdn.com/tmarq/archive/2010/04/14/performing-asynchronous-work-or-tasks-in-asp-net- applications.aspx

谢谢，
托马斯

Answer 6

那篇文章不正确。 ASP.NET 有自己的线程池（托管工作线程），用于服务 ASP.NET 请求。该池通常有几百个线程，并且与 ThreadPool 池分开，后者是处理器的较小倍数。

在 ASP.NET 中使用 ThreadPool 不会干扰 ASP.NET 工作线程。使用ThreadPool就可以了。

设置一个仅用于记录消息并使用生产者/消费者模式将日志消息传递给该线程的线程也是可以接受的。在这种情况下，由于线程是长期存在的，因此您应该创建一个新线程来运行日志记录。

对每条消息使用一个新线程绝对是矫枉过正。

如果您只谈论日志记录，另一种选择是使用像 log4net 这样的库。它在单独的线程中处理日志记录，并处理该场景中可能出现的所有上下文问题。

Answer 7

我想说这篇文章是错误的。如果您正在运营一家大型 .NET 商店，您可以安全地跨多个应用程序和多个网站使用该池（使用单独的应用程序池），只需根据 ThreadPool 文档：

每个进程有一个线程池。
线程池的默认大小为
每个可用工作线程 250 个
处理器和 1000 个 I/O 完成
线程。中的线程数
线程池可以通过使用来更改
SetMaxThreads 方法。每个线程
使用默认堆栈大小并运行
默认优先级。

Answer 8

上周我在工作中被问到了类似的问题，我会给你同样的答案。为什么每个请求都使用多线程 Web 应用程序？ Web 服务器是一个经过大量优化的出色系统，可以及时提供许多请求（即多线程）。想一想当您请求网络上的几乎任何页面时会发生什么。

1. 对某些页面发出请求
2. Html 被返回
3. Html 告诉客户端进行进一步的请求（js、css、图像等）。
4. 返回更多信息

您给出了远程日志记录的示例，但这应该是一个问题你的记录器。应建立异步流程来及时接收消息。 Sam 甚至指出您的记录器 (log4net) 应该已经支持这一点。

Sam 的观点也是正确的，即在 CLR 上使用线程池不会导致 IIS 中的线程池出现问题。不过，这里要关心的是，您不是从进程中生成线程，而是从 IIS 线程池线程中生成新线程。这是有区别的，而且区别很重要。

线程与进程

线程和进程都是方法
并行化应用程序。
然而，进程是独立的
包含自己的执行单元
状态信息，使用自己的
地址空间，并且只与交互
通过进程间相互
沟通机制（一般
由操作系统管理）。
应用程序通常被划分
在设计过程中融入流程
阶段，以及明确的主进程
当它创建时产生子进程
逻辑上分开的意义
重要的应用程序功能。
换句话说，流程是一个
架构构造。

相比之下，线程是一种编码
构造不影响
应用程序的架构。一个
单个进程可能包含多个
线程；进程内的所有线程
共享相同的状态和相同的内存
空间，并且可以与每个人进行交流
其他直接，因为他们共享
相同的变量。

来源

Answer 9

您可以使用 Parallel.For 或 Parallel.ForEach 并定义要分配的可能线程的限制，以平稳运行并防止池不足。

但是，要在后台运行，您将需要在 ASP.Net Web 应用程序中使用下面的纯 TPL 样式。

var ts = new CancellationTokenSource();
CancellationToken ct = ts.Token;

ParallelOptions po = new ParallelOptions();
            po.CancellationToken = ts.Token;
            po.MaxDegreeOfParallelism = 6; //limit here

 Task.Factory.StartNew(()=>
                {                        
                  Parallel.ForEach(collectionList, po, (collectionItem) =>
                  {
                     //Code Here PostLog(logEvent);
                  }
                });

Answer 10

我不同意引用的文章（C#feeds.com）。创建新线程很容易，但很危险。在单个核心上运行的最佳活动线程数实际上低得惊人 - 不到 10 个。如果为次要任务创建线程，则很容易导致机器浪费时间切换线程。线程是一种需要管理的资源。 WorkItem 抽象就是用来处理这个问题的。

这里需要权衡减少可用于请求的线程数量和创建太多线程以允许其中任何线程有效处理。这是一种非常动态的情况，但我认为应该主动管理（在本例中由线程池），而不是将其留给处理器以保持在线程创建之前。

最后，本文对使用 ThreadPool 的危险做了一些非常全面的陈述，但它确实需要一些具体的东西来支持它们。

Answer 11

IIS 是否使用相同的 ThreadPool 来处理传入请求似乎很难得到明确的答案，而且似乎也随着版本的不同而发生了变化。因此，不要过度使用 ThreadPool 线程似乎是个好主意，这样 IIS 就有很多可用的线程。另一方面，为每个小任务生成自己的线程似乎是一个坏主意。据推测，您在日志记录中进行了某种锁定，因此一次只能有一个线程进行，其余线程将轮流进行计划和未计划（更不用说生成新线程的开销）。本质上，您遇到的正是 ThreadPool 旨在避免的问题。

似乎合理的妥协是让您的应用程序分配一个可以向其传递消息的日志记录线程。您需要注意发送消息的速度尽可能快，以免减慢应用程序的速度。