确定适当数量的任务

Question

我正在开发一个小型库，它使用任务并行库来运行并行搜索以寻找解决方案。当前的设计遵循以下原则：

• ConcurrentQueue 接收 Searches 的结果，
• 主任务作为循环运行，作为后台线程运行。当一个新的解决方案到达队列时，它会出列并处理它，然后在一个新任务上启动一个新的搜索，
• 搜索在其自己的任务中启动，并在完成后将其结果返回到队列。

[根据 Eric J 的回答编辑：所涉及的活动完全受 CPU 限制，不涉及 IO]

该框架目前运行良好。但是，我可以完全控制将触发的搜索任务的数量，并且我的理解是，虽然 TPL 目前可以很好地处理这种情况，但将大量搜索推向系统不会导致并行度增加，因为它会受到系统上可用的核心数量的限制，并且在达到一定水平后会适得其反。

我的问题如下：我可以通过限制将运行的搜索任务的数量来“帮助”TPL，如果可以，我将如何确定上限应该是多少？例如基于 System.Environment.ProcessorCount 限制它是否合适？

Answer 1

首先，除非这里存在真正的性能问题，否则我只会让 TPL 来做这件事。这方面做得很好。

如果您确实需要控制任务数量来解决实际性能问题，您需要了解限制性能的因素。您的任务受 CPU 限制吗？ IO绑定？物理内存不足导致交换吗？

一旦您知道限制因素是什么，您当然可以监控该因素并根据该（运行时）测量值调整运行任务的数量。例如，如果您的任务受 CPU 限制但有一些 IO 时间，则基于内核数的硬限制很接近但不是最佳的。而是根据整体 CPU 利用率进行限制。 这假设机器主要用于处理此任务。否则，手动调整会更加复杂且容易出错。