我们将在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内核
答案 0 :(得分:0)
您真正要问的是同步和异步之间的区别。用非常基本术语来说,异步允许进行线程切换,即工作从一个线程开始,而在另一个线程上完成,而同步保持在同一线程上。
如果没有特定应用程序中发生的情况的上下文,这本身并没有多大意义。对于Web应用程序,您有一个线程池。 通常线程池由1000个线程组成,因为这是Web服务器上的典型默认值。这个数字可以更少或更多;这对于这次讨论并不重要。但是,必须注意,池中的最大线程数存在非常实际的物理限制。因为每个人都会消耗一些系统资源。
因此,该线程池通常也称为“最大请求数”,因为通常来说一个请求=一个线程。因此,如果线程池为1000,则理论上可以处理1000个并发请求。线程中的任何一个可用时,所有超出该队列的内容都将被处理。这就是异步信号的来源。
异步工作几乎是I / O工作:查询数据库,读/写文件系统,向其他服务(例如API)发出请求等。所有这些工作通常都有一段时间的空闲时间时间。例如,对于数据库查询,您进行查询,然后等待。查询要花费一些时间才能到达数据库服务器,数据库服务器要处理它并生成结果集,然后数据库服务器将结果发送回去。异步允许在此期间将活动线程返回到池中,然后它可以为其他请求提供服务。这样,假设您有一个这样的操作正在进行数据库查询,如果它是同步的,并且您收到1001个同时请求到该操作的请求,则前1000个将开始处理,最后一个将进入队列。在其他1000个请求中的一个完全完成之前,无法处理最后一个请求。而使用异步功能,只要将一千个查询传递给数据库服务器,它就可以返回到线程池以处理该等待的请求。
这都是一个较高的层次。实际上,有一个 lot 可以解决这个问题,实际上并不是那么简单。异步不保证该线程将被释放。某些工作,特别是与CPU绑定的工作,永远都不会是异步的,因此,即使您使用异步方法进行操作,它也会像同步一样运行。但是,通常来说,在线程匮乏的情况下,异步处理的请求比同步处理的要多。虽然确实要付出代价。即使线程很小,在线程之间切换的额外工作也会增加一些开销,因此异步几乎总是比同步慢,即使只有纳秒。但是,异步与 scale 有关,而不是与性能有关,而性能下降通常是可以扩展的扩展能力所能接受的。