基于任务的并发比直接使用 System.Threading.Thread 慢得多

Question

我一直在使用 System.Threading.Task 和 System.Net.Http.HttpClient 对 Web 服务器进行负载测试，并观察到一些奇怪的行为。代码如下：

var taskArray = new List<Task>();              
for (int i = 0; i < 105; i++)
    taskArray.Add(Task.Factory.StartNew(() => Get("/content/test.jpg")));

Task.WaitAll(taskArray.ToArray());

即使每个请求（通过提琴手监控时）只需要大约 15 毫秒的时间来执行，我还是收到了由用于发出请求的 HttpClient 引发的超时异常（嗯，TaskCanceledExcpetions - 这是同一件事）。请求时间超过了 100 秒的默认超时时间。

我尝试的第一件事是增加 HttpClient 的超时，这很有效，但我仍然难以理解为什么响应时间很短的请求会超时。因此，我在调用 HttpClient.PostAsync 之前设置了一个计时器，并检查了完成所需的时间，正如怀疑的那样，时间超过了 100 秒，尽管服务器发送响应的速度要快得多。

然后我读到 HttpClient.Timeout 是整个异步操作的超时时间，这让我认为可能是任务调度程序导致我出现问题，因为它仅在响应准备好后执行接收响应的异步回调很长时间收到。

考虑到这一点，我决定使用旧的 System.Threading.Thread 编写代码：

var handle = new EventWaitHandle(false, EventResetMode.ManualReset);
for (int i = 0; i < 105; i++)
{
    var t = new Thread(() =>
    {
        Get("/content/test.jpg");
        if (Interlocked.Decrement(ref numberOfTasks) == 0)
            handle.Set();
    });
    t.Start();
}

handle.WaitOne();

这按预期工作！我什至可以将线程数增加到 2000，它完成所有线程的速度比基于任务的版本发送 105 更快！

什么给了？

Answer 1

正如 Matthew 所说，这是因为 Task 工厂默认使用线程池。如果您想使用任务并想提高线程池限制，稍微提高限制或创建自己的线程池可能对您有一些价值。

也就是说，您已经在使用具有所有异步方法的类：您为什么要尝试将它们包装在线程中？只需捕获任务并等待它们。

类似这样的：

var tasks = new List<Task>();              
for (int i = 0; i < 105; i++)
    tasks.Add(client.GetAsync(uri));

Task.WaitAll(tasks.ToArray());