有太多任务会有什么影响？

Question

我目前正在开发一个应用程序，该应用程序依赖于许多不同的Web服务来获取数据。因为我想模块化每个服务并在其中添加一些依赖关系（例如service1必须在service2和3之前运行），所以我在每个服务中运行它自己的任务。

这些任务本身可以是：

1. 主动运行，这意味着它们正在向Web服务发送请求并等待响应或处理响应

2. 等待（通过监视器和超时）- 一旦任务完成，所有等待任务都会唤醒并检查它们的依赖项是否已完成

现在，系统以我认为良好的性能运行（尤其是由于性能相当可忽略），但是应用程序会生成相当数量的任务。

那么，我的问题是：在这种情况下200个任务是否太多？它们是否会产生太多开销，以至于基本上非线程化的方法更好？

- Scurals

---

这可能取决于(1)需要完成的任务和(2)模块的粒度。 - Willem Van Onsem

任务大多只是向Web服务发送请求，即发送请求以获取Twitter提要，并进行极小的处理（过滤推文）。我为每个项目启动一个新任务，意味着同时运行约1-30个任务，而不等待依赖关系---通常每个Web服务模块一个（目前总共约10-15个模块）。 - Scurals

在我看来，这是可行的，因为“运行”仅意味着等待服务器的响应... - Willem Van Onsem

答案取决于这些任务的具体内容。你说了是网络请求，为什么不使用异步方式呢？如果你使用异步方式，就不需要担心资源问题了。 - Sriram Sakthivel

Answer 1

一般来说，“度量、度量、再度量”:) 如果你没有遇到性能问题，就不应该开始优化。

我认为200个任务还是可以的。与“真正”的线程甚至线程池相比，任务的优点在于低开销。TaskScheduler通过各种技巧（例如串行运行子任务、从其他线程的队列中窃取工作等）尽可能利用所有硬件线程，并具有最少的线程切换。

您还可以通过TaskCreationOptions向TaskScheduler提供有关特定任务要执行的操作的一些提示。

---

如果您想了解一些数字，请查看此帖子，如您所见，TPL在开销方面非常便宜：
.NET 4.0 - Task Parallel Library (TPL) 的性能，作者：Daniel Palme

这是另一篇有趣的文章：
CLR Inside Out：使用并发实现可伸缩性，作者：Joe Duffy

- aL3891

---

“另一篇有趣的文章”已经失效了 - 你还记得它指的是什么吗？ - default

我认为这个死链接指的是2006年9月的一篇文章，题为“CLR Inside Out: Using concurrency for scalability”。由于这篇文章太旧了，微软已经将其存档。您可以在此处尝试在线查看：https://web.archive.org/web/20130608013159/http://msdn.microsoft.com/en-us/magazine/cc163552.aspx 或者您可以在此处下载存档的CHM版本：http://download.microsoft.com/download/3/a/7/3a7fa450-1f33-41f7-9e6d-3aa95b5a6aea/MSDNMagazineSeptember2006en-us.chm（您可能需要在阅读内容之前“解除阻止”该文件）。 - user1289580

那篇文章的链接似乎已经被重定向了，所以现在可以正常使用。 - aL3891