blocks|key|1255355|text|网站不应该到处散布帖子。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1255356|您通常将此功能移到Windows服务中，然后与之通信(我使用MSMQ与它们通信)。|1255357|--编辑|1255358|我在这里描述了一个实现：Queue-Based+Background+Processing+in+ASP.NET+MVC+Web+Application|offset|length|1255359|1255360|要扩展为什么这比线程更好：|1255361|使用MSMQ，您可以与另一台服务器通信。您可以跨机器写入一个队列，因此，如果出于某种原因，您确定您的后台任务消耗了太多主服务器的资源，那么您可以很容易地转移它。|1255362|它还允许你批量处理你想要做的任何任务(发送电子邮件/任何东西)。|1255363|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/1317641/queue-based-background-processing-in-asp-net-mvc-web-application^0|0|0|0|C|1S|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@$H|12|I|13|1|14]]|A|$]]|$1|J|3|E|5|6|7|15|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|16|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|17|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]]]

Websites shouldn't go around spawning threads.

You typically move this functionality out into a Windows Service that you then communicate with (I use MSMQ to talk to them).

-- Edit

I described an implementation here: <a href="https://stackoverflow.com/questions/1317641/queue-based-background-processing-in-asp-net-mvc-web-application">Queue-Based Background Processing in ASP.NET MVC Web Application</a>

-- Edit

To expand why this is even better than just threads:

Using MSMQ, you can communicate to another server. You can write to a queue across machines, so if you determine, for some reason, that your background task is using up the resources of the main server too much, you can just shift it quite trivially.

It also allows you to batch-process whatever task you were trying to do (send emails/whatever).

blocks|key|1470086|text|我绝对认为，在ASP.NET中快速、低优先级异步工作的一般实践是使用.NET线程池，特别是对于高流量场景，因为您希望您的资源是有限的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1470087|此外，线程的实现是隐藏的-如果你开始产生你自己的线程，你也必须正确地管理它们。并不是说你做不到，但为什么要重新发明那个轮子呢？|1470088|如果性能成为一个问题，并且您可以确定线程池是限制因素(而不是数据库连接、传出网络连接、内存、页面超时等)，那么您可以调整线程池配置以允许更多的工作线程、更高队列的请求等。|1470089|如果没有性能问题，那么选择派生新线程来减少与ASP.NET请求队列的争用是典型的过早优化。|1470090|理想情况下，您不需要使用单独的线程来执行日志记录操作-只需使原始线程尽可能快地完成操作，这就是MSMQ和单独的使用者线程/进程的用武之地。我同意这是更重和更多的工作来实现，但你真的需要在这里的持久性-共享，内存队列的波动性将很快耗尽它的欢迎。|1470091|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I definitely think that general practice for quick, low-priority asynchronous work in ASP.NET would be to use the .NET thread pool, particularly for high-traffic scenarios as you want your resources to be bounded. 

Also, the implementation of threading is hidden - if you start spawning your own threads, you have to manage them properly as well. Not saying you couldn't do it, but why reinvent that wheel?

If performance becomes an issue, and you can establish that the thread pool is the limiting factor (and not database connections, outgoing network connections, memory, page timeouts etc) then you tweak the thread pool configuration to allow more worker threads, higher queued requests, etc. 

If you don't have a performance problem then choosing to spawn new threads to reduce contention with the ASP.NET request queue is classic premature optimization.

Ideally you wouldn't need to use a separate thread to do a logging operation though - just enable the original thread to complete the operation as quickly as possible, which is where MSMQ and a separate consumer thread / process come in to the picture. I agree that this is heavier and more work to implement, but you really need the durability here - the volatility of a shared, in-memory queue will quickly wear out its welcome.

blocks|key|1470133|text|那篇文章不正确。ASP.NET有自己的线程池，即托管工作线程，用于服务ASP.NET请求。这个池通常只有几百个线程，与ThreadPool池是分开的，后者是一些较小的处理器倍数。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1470134|在ASP.NET中使用ThreadPool不会干扰ASP.NET工作线程。使用ThreadPool就可以了。|1470135|还可以设置单个线程，该线程仅用于记录消息，并使用生产者/消费者模式将日志消息传递给该线程。在这种情况下，由于线程是长期存在的，因此您应该创建一个新线程来运行日志记录。|1470136|对每条消息使用一个新的线程肯定是大材小用了。|1470137|另一种选择是，如果您只讨论日志记录，则可以使用像log4net这样的库。它在单独的线程中处理日志记录，并处理该场景中可能出现的所有上下文问题。|1470138|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

That article is not correct. ASP.NET has it's own pool of threads, managed worker threads, for serving ASP.NET requests. This pool is usually a few hundred threads and is separate from the ThreadPool pool, which is some smaller multiple of processors.

Using ThreadPool in ASP.NET will not interfere with ASP.NET worker threads. Using ThreadPool is fine.

It would also be acceptable to setup a single thread which is just for logging messages and using producer/consumer pattern to pass logs messages to that thread. In that case, since the thread is long-lived, you should create a single new thread to run the logging.

Using a new thread for every message is definitely overkill.

Another alternative, if you're only talking about logging, is to use a library like log4net. It handles logging in a separate thread and takes care of all the context issues that could come up in that scenario.

blocks|key|1470200|text|我不同意引用的文章(C#feeds.com)。创建一个新线程很容易，但却很危险。在单核上运行的最优活动线程数实际上令人惊讶地低--少于10个。如果线程是为次要任务创建的，那么很容易导致机器浪费时间切换线程。线程是一种需要管理的资源。WorkItem抽象就是用来处理这个问题的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1470201|在减少可用于请求的线程数量和创建太多线程以允许它们中的任何一个有效处理之间存在权衡。这是一种非常动态的情况，但我认为应该主动管理(在本例中由线程池管理)，而不是让处理器在线程创建之前保持领先。|1470202|最后，这篇文章对使用ThreadPool的危险做了一些相当笼统的陈述，但它确实需要一些具体的东西来支持它们。|1470203|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I do not agree with the referenced article(C#feeds.com). It is easy to create a new thread but dangerous. The optimal number of active threads to run on a single core is actually surprisingly low - less than 10. It is way too easy to cause the machine to waste time switching threads if threads are created for minor tasks. Threads are a resource that REQUIRE management. The WorkItem abstraction is there to handle this.

There is a trade off here between reducing the number of threads available for requests and creating too many threads to allow any of them to process efficiently. This is a very dynamic situation but I think one that should be actively managed (in this case by the thread pool) rather than leaving it to the processer to stay ahead of the creation of threads.

Finally the article makes some pretty sweeping statements about the dangers of using the ThreadPool but it really needs something concrete to back them up.

blocks|key|1255626|text|IIS是否使用相同的ThreadPool来处理传入的请求似乎很难得到一个明确的答案，而且似乎在不同的版本上也有所不同。因此，不要过度使用IIS线程似乎是个好主意，这样ThreadPool就有很多可用的线程。另一方面，为每个小任务创建自己的线程似乎不是一个好主意。想必，您的日志记录中存在某种锁定，因此一次只能处理一个线程，而其余线程将轮流进行调度和非调度(更不用说产生新线程的开销了)。从本质上讲，您遇到的问题正是ThreadPool旨在避免的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1255627|对于你的应用程序来说，一个合理的折衷方案是分配一个可以传递消息的日志线程。你需要注意发送消息的速度越快越好，这样就不会减慢你的应用程序的速度。|1255628|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Whether or not IIS uses the same ThreadPool to handle incoming requests seems hard to get a definitive answer to, and also seems to have changed over versions. So it would seem like a good idea not to use ThreadPool threads excessively, so that IIS has a lot of them available. On the other hand, spawning your own thread for every little task seems like a bad idea. Presumably, you have some sort of locking in your logging, so only one thread could progress at a time, and the rest would just take turns getting scheduled and unscheduled (not to mention the overhead of spawning a new thread). Essentially, you run into the exact problems the ThreadPool was designed to avoid.

It seems that a reasonable compromise would be for your app to allocate a single logging thread that you could pass messages to. You would want to be careful that sending messages is as fast as possible so that you don't slow down your app.

blocks|key|1470355|text|你应该使用QueueUserWorkItem，并且避免创建新的线程，就像避免瘟疫一样。对于解释为什么您不会饿死ASP.NET的视觉效果，因为它使用相同的ThreadPool，想象一下一个非常熟练的杂耍演员用两只手保持半打保龄球、剑或任何东西在飞行。想要直观地了解为什么创建自己的线程是不好的，想象一下在高峰时间西雅图会发生什么，当繁忙的高速公路入口坡道允许车辆立即进入交通，而不是使用灯光，并将入口数量限制为每几秒钟一个。最后，有关详细说明，请查看此链接：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1470356|http://blogs.msdn.com/tmarq/archive/2010/04/14/performing-asynchronous-work-or-tasks-in-asp-net-applications.aspx|offset|length|1470357|谢谢，托马斯|1470358|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|35|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@$D|Q|E|R|1|S]]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|C]]]]

You should use QueueUserWorkItem, and avoid creating new threads like you would avoid the plague. For a visual that explains why you won't starve ASP.NET, since it uses the same ThreadPool, imagine a very skilled juggler using two hands to keep a half dozen bowling pins, swords, or whatever in flight. For a visual of why creating your own threads is bad, imagine what happens in Seattle at rush hour when heavily used entrance ramps to the highway allow vehicles to enter traffic immediately instead of using a light and limiting the number of entrances to one every few seconds. Finally, for a detailed explanation, please see this link:

<a href="http://blogs.msdn.com/tmarq/archive/2010/04/14/performing-asynchronous-work-or-tasks-in-asp-net-applications.aspx" rel="nofollow noreferrer">http://blogs.msdn.com/tmarq/archive/2010/04/14/performing-asynchronous-work-or-tasks-in-asp-net-applications.aspx</a>

Thanks,
Thomas

blocks|key|1470429|text|您可以使用Parallel.For或Parallel.ForEach，并定义为平稳运行和防止池资源匮乏而分配的可能线程的限制。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1470430|但是，在后台运行时，您需要在ASP.Net+web应用程序中使用下面的纯第三方逻辑样式。|1470431|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);
++++++++++++++++++}
++++++++++++++++});|code-block|syntax|javascript|1470432|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

You can use Parallel.For or Parallel.ForEach and define the limit of possible threads you want to allocate to run smoothly and prevent pool starvation.

However, being run in background you will need to use pure TPL style below in ASP.Net web application.

<pre><code>var ts = new CancellationTokenSource();
CancellationToken ct = ts.Token;

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

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

I've always been under the impression that using the ThreadPool for (let's say non-critical) short-lived background tasks was considered best practice, even in ASP.NET, but then I came across <a href="http://csharpfeeds.com/post/5415/Dont_use_the_ThreadPool_in_ASP.NET.aspx" rel="noreferrer">this article</a> that seems to suggest otherwise - the argument being that you should leave the ThreadPool to deal with ASP.NET related requests.

So here's how I've been doing small asynchronous tasks so far:

<pre><code>ThreadPool.QueueUserWorkItem(s =&gt; PostLog(logEvent))
</code></pre>

And <a href="http://csharpfeeds.com/post/5415/Dont_use_the_ThreadPool_in_ASP.NET.aspx" rel="noreferrer">the article</a> is suggesting instead to create a thread explicitly, similar to:

<pre><code>new Thread(() =&gt; PostLog(logEvent)){ IsBackground = true }.Start()
</code></pre>

The first method has the advantage of being managed and bounded, but there's the potential (if the article is correct) that the background tasks are then vying for threads with ASP.NET request-handlers. The second method frees up the ThreadPool, but at the cost of being unbounded and thus potentially using up too many resources.

So my question is, is the advice in the article correct?

If your site was getting so much traffic that your ThreadPool was getting full, then is it better to go out-of-band, or would a full ThreadPool imply that you're getting to the limit of your resources anyway, in which case you shouldn't be trying to start your own threads?

Clarification: I'm just asking in the scope of small non-critical asynchronous tasks (eg, remote logging), not expensive work items that would require a separate process (in these cases I agree you'll need a more robust solution).

Using ThreadPool.QueueUserWorkItem in ASP.NET in a high traffic scenario

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我一直认为，将ThreadPool用于(比如说非关键的)短暂的后台任务被认为是最佳实践，即使在ASP.NET中也是如此，但是后来我发现似乎提出了不同的建议-其论点是您应该让ThreadPool来处理与ASP.NET相关的请求。到目前为止，我一直在做一些小的异步任务：ThreadPool.QueueUserWorkIte...

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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