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);
}

如果要执行异步任务，我们是否也应使用EF异步，我们还将为此新API使用EF内核

Answer 1

您真正要问的是同步和异步之间的区别。用非常基本术语来说，异步允许进行线程切换，即工作从一个线程开始，而在另一个线程上完成，而同步保持在同一线程上。

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

因此，该线程池通常也称为“最大请求数”，因为通常来说一个请求=一个线程。因此，如果线程池为1000，则理论上可以处理1000个并发请求。线程中的任何一个可用时，所有超出该队列的内容都将被处理。这就是异步信号的来源。

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

这都是一个较高的层次。实际上，有一个 lot 可以解决这个问题，实际上并不是那么简单。异步不保证该线程将被释放。某些工作，特别是与CPU绑定的工作，永远都不会是异步的，因此，即使您使用异步方法进行操作，它也会像同步一样运行。但是，通常来说，在线程匮乏的情况下，异步处理的请求比同步处理的要多。虽然确实要付出代价。即使线程很小，在线程之间切换的额外工作也会增加一些开销，因此异步几乎总是比同步慢，即使只有纳秒。但是，异步与 scale 有关，而不是与性能有关，而性能下降通常是可以扩展的扩展能力所能接受的。

IActionResult或异步Task <iactionresult>有什么优点？

1 个答案: