有多少任务太多了？答案

【问题标题】：How many tasks are too many?有多少任务太多了？
【发布时间】：2013-10-13 17:31:55
【问题描述】：

我目前正在开发一个依赖于许多不同 Web 服务来获取数据的应用程序。由于我想对每个服务进行模块化并在其中有一些依赖（service1 必须在服务 2 和 3 之前运行等），所以我在自己的任务中运行每个服务。

任务本身要么是

现在，系统正在以我所谓的良好性能运行（特别是因为性能相当可忽略不计） - 但是，应用程序会生成相当多的任务。

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

【问题讨论】：

这可能取决于 (1) 必须完成的任务和 (2) 模块的粒度。
这些任务大多只是向网络服务发送请求，即发送一个推特订阅请求，处理非常小（过滤推文）。我为每个项目启动一个新任务，这意味着大约 1-30 个任务“同时”运行并且不等待依赖 --- 通常每个 web 服务大约一个模块（目前总共大约 10-15 个模块）。
在我看来这是可行的，因为“运行”仅仅意味着等待服务器的响应......
答案取决于这些任务的作用。你说web请求，为什么不异步呢？如果你做异步，那么你不需要担心资源

【解决方案1】：

一般的答案是“测量、测量、测量”:) 如果您没有遇到任何性能问题，则不应开始优化。

不过，我会说 200 个任务很好。与线程相比，任务的美妙之处在于它们与“真实”线程甚至线程池相比开销较低。 TaskScheduler 确保以最少的线程切换量尽可能多地利用所有硬件线程。它通过各种技巧来做到这一点，例如串行运行子任务、从其他线程的队列中窃取工作等等。

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

如果您想要一些数字，请查看这篇文章，如您所见，Tpl 在开销方面非常便宜：
.NET 4.0 - Performance of Task Parallel Library (TPL), by Daniel Palme

【讨论】：

“另一篇有趣的文章”已经死了——你还记得它指的是什么吗？
我相信死链接指的是 2006 年 9 月的一篇文章，“CLR Inside Out：使用并发实现可伸缩性”。由于文章太旧，MS 将其存档。您可以尝试在此处在线查看：web.archive.org/web/20130608013159/http://msdn.microsoft.com/… 或者您可以在此处下载存档的 CHM 版本：download.microsoft.com/download/3/a/7/…（您可能需要“解锁”文件才能阅读内容）。
该文章的链接似乎已重新路由，因此现在可以再次使用