IActionResult 或 async Task<IActionResult> 有什么好处？

Question

我们将在 dotnet core 2.1 中创建一个新的 API，这个 Web API 将是一个高流量/事务，例如每分钟 10,000 或更高。我通常像下面这样创建我的 API。

[HttpGet("some")]
public IActionResult SomeTask(int id)
{
   var result = _repository.GetData(id)
   return Ok(result);
}

如果我们像下面这样实现我们的 Web API，会有什么好处？

[HttpGet("some")]
public async Task<IActionResult> SomeTask(int id)
{
    await result = _repository.GetData(id);
    return Ok(result);
}

我们还将为这个新 API 使用 EF 核心，如果我们执行异步任务，我们是否也应该使用 EF 异步

Answer 1

您真正要问的是同步和异步之间的区别。在非常基本术语中，异步允许线程切换的可能性，即工作在一个线程上开始，但在另一个线程上结束，而同步保持在同一个线程上。

如果没有特定应用程序中正在发生的事情的上下文，这本身并没有多大意义。对于 Web 应用程序，您有一个线程池。线程池通常由 1000 个线程组成，因为这是跨 Web 服务器的典型默认设置。这个数字可以更少或更多；这对这个讨论并不重要。不过，重要的是要注意，池中的最大线程数有一个非常实际的物理限制。因为每一个都会消耗一些系统资源。

因此，这个线程池通常也被称为“最大请求数”，因为一般来说一个请求 = 一个线程。因此，如果你有 1000 个线程池，理论上可以同时服务 1000 个请求。任何超过该队列的内容都会在其中一个线程可用后进行处理。这就是异步的用武之地。

异步工作几乎是 I/O 工作：查询数据库、读取/写入文件系统、向其他服务（例如 API）发出请求等。所有这些工作通常都会有一段时间的空闲时间。例如，对于数据库查询，您进行查询，然后等待。查询需要一些时间才能到达数据库服务器，数据库服务器处理它并生成结果集，然后数据库服务器将结果发回。异步允许在这些期间将活动线程返回到池中，然后它可以在其中为其他请求提供服务。因此，假设您有这样的操作正在进行数据库查询，如果它是同步的并且您收到了 1001 个对该操作的同时请求，则前 1000 个将开始处理，最后一个将成为队列。在其他 1000 个请求中的一个完全完成之前，无法处理最后一个请求。然而，使用异步，一旦千人中的一个将查询交给数据库服务器，它就可以返回到线程池以处理该等待请求。

这都是有点高级。实际上，有一个 lot 涉及到这一点，这真的不是那么简单。 Async 不保证线程会被释放。某些工作，特别是受 CPU 限制的工作，永远不可能是异步的，所以即使你在异步方法中执行它，它也会像同步一样运行。但是，一般来说，在线程匮乏的情况下，异步将处理比同步更多的请求。不过，这确实是有代价的。在线程之间切换的额外工作增加了一些开销，即使它是微不足道的，所以异步几乎总是比同步慢，即使只有纳秒。但是，异步是关于规模，而不是性能，而且性能损失通常是可以接受的交易，以提高扩展能力。