为什么异步控制器方法像同步方法一样执行？

Question

我创建了示例 .NET Core WebApi 应用程序来测试异步方法如何提高吞吐量。应用托管在 IIS 10 上。

这是我的控制器的代码：

[HttpGet("sync")]
public IEnumerable<string> Get()
{
    return this.GetValues().Result;
}

[HttpGet("async")]
public async Task<IEnumerable<string>> GetAsync()
{
    return await this.GetValues();
}

[HttpGet("isresponding")]
public Task<bool> IsResponding()
{
    return Task.FromResult(true);
}

private async Task<IEnumerable<string>> GetValues()
{
    await Task.Delay(TimeSpan.FromSeconds(10)).ConfigureAwait(false);
    return new string[] { "value1", "value2" };
}

有一些方法： Get() - 同步获取结果 GetAsync() - 异步获取结果。 IsResponding() - 检查服务器是否可以处理请求

然后我创建了示例控制台应用程序，它创建了 100 个控制器的同步请求和异步方法（不等待结果）。然后我调用方法IsResponding() 来检查服务器是否可用。

控制台应用代码是：

      using (var httpClient = new HttpClient())
      {
        var methodUrl = $"http://localhost:50001/api/values/{apiMethod}";
        Console.WriteLine($"Executing {methodUrl}");
        //var result1 = httpClient.GetAsync($"http://localhost:50001/api/values/{apiMethod}").Result.Content.ReadAsStringAsync().Result;

        Parallel.For(0, 100, ((i, state) =>
        {
          httpClient.GetAsync(methodUrl);
        }));

        var sw = Stopwatch.StartNew();
        var isAlive = httpClient.GetAsync($"http://localhost:50001/api/values/isresponding").Result.Content;
        Console.WriteLine($"{sw.Elapsed.TotalSeconds} sec.");

        Console.ReadKey();
      }

其中{apiMethod} 是“同步”或“异步”，具体取决于用户输入。

在这两种情况下，服务器都长时间没有响应（大约 40 秒）。 我解释说，在异步情况下，服务器应该继续快速服务请求，但事实并非如此。

更新 1： 我已经像这样更改了客户端代码：

  Parallel.For(0, 10000, ((i, state) =>
  {
    var httpClient = new HttpClient();
    httpClient.GetAsync($"http://localhost:50001/api/values/{apiMethod}");
  }));

  using (var httpClient = new HttpClient())
  {
    var sw = Stopwatch.StartNew();
    // this method should evaluate fast when we called async version and should evaluate slowly when we called sync method (due to busy threads ThreadPool)
    var isAlive = httpClient.GetAsync($"http://localhost:50001/api/values/isresponding").Result.Content;
    Console.WriteLine($"{sw.Elapsed.TotalSeconds} sec.");
  }

并调用IsResponding()方法执行了很长时间。

更新 2 是的，我知道异步方法是如何工作的。是的，我知道如何使用 HttpClient。这只是一个证明理论的样本。

更新 3 正如 StuartLC 在其中一个 cmets 中提到的，IIS 以某种方式限制或阻止请求。当我以 SelfHosted 身份启动 WebApi 时，它开始按预期工作：

1. 在向 ASYNC 方法发出一堆请求后，“isresponsible”方法的执行时间非常快，约为 0.02 秒。
2. 在向 SYNC 方法发出一堆请求后，“isresponsible”方法的执行时间非常慢，大约为 35 秒。

Answer 1

您似乎不了解异步。它不会使响应返回更快。在操作正在执行的所有操作（异步与否）完成之前，无法返回响应。如果有的话，异步实际上更慢，即使只是轻微的，因为异步处理涉及额外的开销，而同步处理不是必需的。

异步所做 所做的可能是允许为请求提供服务的活动线程返回到池中以服务其他请求。换句话说，异步是关于规模，而不是性能。只有当您的服务器收到大量请求时，您才会看到好处。然后，当传入的请求通常已排队同步时，您将处理来自某些异步任务的额外请求，从而将其线程丧失为原因。此外，不能保证线程将被释放。如果异步任务立即或接近立即完成，线程将被暂停，就像同步一样。

编辑

您还应该意识到 IIS Express 是单线程的。因此，它不是性能调优的好指标。如果您同时运行 1000 个请求，则有 999 个会立即排队。然后，您没有做任何异步工作 - 只是返回一个已完成的任务。因此，线程永远不会被释放，因此在这种情况下同步和异步之间实际上没有区别。因此，您可以确定处理 999 个请求的队列需要多长时间（加上最后的状态检查）。如果您执行以下操作，您可能会更幸运地找出差异：

await Task.Delay(500);

而不仅仅是返回Task.FromResult。这样，线程上就有实际的空闲时间，可以让它返回到池中。

Answer 2

IIS 以某种方式限制或阻止请求（如其中一个 cmets 中所述）。当我以 SelfHosted 身份启动 WebApi 时，它开始按预期工作：

isresponsible 方法在向 ASYNC 方法发出一堆请求后的执行时间非常快，大约为 0.02 秒。 isresponsible 方法在对 SYNC 方法的一堆请求之后的执行时间很慢，大约 35 秒。

Answer 3

我不确定这是否会产生任何重大改进，但您应该在服务器中的每个可等待对象上调用 ConfigureAwait(false)，包括在 GetAsync 中。

它应该更好地利用线程。