不，主要是因为任务没有定义。一个任务可以是CPU密集型的（限制类似于Cores * factor）、IO密集型的（限制可以非常低）或网络密集型的（限制不喜欢同时处理1000个请求）。
因此，作为一个程序员，你需要开动脑筋，想出一个概念，然后验证它，然后把它放到你的程序中，这取决于任务实际是什么，瓶颈在哪里。这样的计划可能很复杂--非常复杂--但大多数时候它是相当简单的。

TPL将自动更改任务的调度方式，并随着时间的推移添加或删除ThreadPool线程。这意味着，如果有足够的时间和类似的工作，默认行为 * 应该 * 改进为最佳选择。
默认情况下，它将使用比核心更多的线程启动，因为许多任务不是“纯CPU”。鉴于您看到额外的任务导致了速度的降低，您可能会有资源争用（通过锁定），或者您的任务受限于CPU，并且任务数量超过处理器内核将导致速度的降低。如果这会有问题，您可以创建一个自定义的TaskScheduler来限制一次允许的任务数量，例如LimitedConcurrencyTaskScheduler。这允许您在纯CPU方案中将任务数限制为处理器数。
如果您的任务受到其他因素（如IO）的约束，则可能需要分析以确定并发调度任务数和吞吐量之间的最佳平衡，尽管这将是特定于系统的。

假设您的任务是CPU密集型的（即它们不会执行大量的I/O阻塞，例如阅读文件），您可能希望将并行任务的数量限制在应用程序可用的CPU内核数量之内。例如，如果您的应用程序运行在配备四核处理器（即4个核心），限制为4个同时执行的任务。
如果您的任务受到CPU以外的其他因素的限制（例如：磁盘访问、网络访问等），然后您需要计算每个任务平均占用的资源份额。如果你知道平均值，那么为了充分利用你的资源，你应该运行的任务数是100 / average。

我带来了这个
一般来说，这是指导方针：

number-of-tasks = (task-total-run-time / task-cpu-bounded-run-time) * number-of-cores

对于真实的计算：

number-of-tasks = Ceil(Avg(task-total-run-time / task-cpu-bounded-run-time) * Max((number-of-cores - 1), 1))

说明：

number-of-tasks-并行运行的任务数
task-total-run-time-异步方法的总运行时间（毫秒）
task-cpu-bounded-run-time-异步方法使用核心cpu的时间（毫秒）
number-of-cores-可用的真实的或虚拟核心的数量（例如在docker容器的情况下），由于一个核心用于主线程而不是工作线程，因此减去1，对于1核心环境，它将是最小值1

备注：

• 如何知道Avg(task-total-run-time / task-cpu-bounded-run-time)：A需要在真实的环境中进行测量，以计算出平均时间比是多少
• 对于最大任务数，应该有一些上限，即使它们几乎完全不受cpu限制，例如128，这也应该考虑在内。
  示例：

对于8内核，平均运行时间如下所示

public async Task UpdateScoreAsync(string requestId)
{
    var res = await GetFromDB(requestId).ConfigureAwait(false); // not cpu bounded, 10 seconds

    int resScore = CalculateScore(res); // cpu bounded, 20 seconds

    await UpdateScoreInDB(requestId, resScore).ConfigureAwait(false); // not cpu bounded, 20 seconds
}

因此，您可以运行的执行此操作的任务数（如果这是您仅有的一个）为12任务

12 = Ceil(((10 + 20 + 20) / (10 + 20)) * (8 - 1))