为什么EF 6教程使用异步调用？

Question

关于如何在MVC 5中使用EF 6的最新EF教程似乎倾向于使用对数据库的asych调用，如下所示：

Department department = await db.Departments.FindAsync(id);

这是新的标准/最佳做法吗？

我不知道用ASP.NET MVC开发这种风格有什么好处。

有人能评论这个模式吗，这是微软正在推广的新标准吗？

Answer 1

为了决定是异步还是同步，比较一下好处和成本：

异步：

• 几乎从不用异步耗尽线程池(情况必须是极端的)。
• 几乎任意级别的并发(并发请求和操作)
• 每个线程保存1MB内存
• 多亏了SynchronizationContext，安全的请求内并发
• 由于减少操作系统调度开销，可以在高负载情况下以较低的两位数百分比增加吞吐量。尽管如此，几乎没有生产应用程序在高CPU负载下，因为如果它是接近不可用的(在负载高峰的情况下，应用程序开始放弃请求)。

同步：

• 简单的代码:等待使99%的情况(几乎)与同步代码一样简单。也就是说，堆栈溢出上的10+异步问题每天都会讲不同的语言。当你偏离简单的路径时，就会出现边缘情况。此外，当使用遗留库时，例如，要求您将同步回调传递给它们时。
• 较少的编码和调试工作
• 分析器友好(您可以分析应用程序或暂停调试器，看看应用程序现在正在做什么。)不可能使用异步。)
• 与遗留代码和库完美地互操作。

如果您正在调用高延迟服务，将选择带有ASP.NET的异步服务。 web服务很可能是高延迟的。OLTP数据库几乎总是低延迟。

如果您的应用程序受益于非常高的并发级别()，则选择异步。大多数应用程序没有这么高的级别，否则它们的后端服务将无法承受如此大的负载。没有意义，使网络应用的规模，但超载的后端。调用链中的所有系统都必须受益于高度的并发性，这样异步才能受益。

典型的高延迟服务(异步的好例子)：

• 网络服务
• 等待(如睡眠)
• 节流(SemaphoreSlim .)
• 一些云服务(Azure)
• 对数据库的长期查询(例如报告或ETL)

典型的低延迟服务(很好的同步用例)：

• 数据库调用:大多数OLTP查询都是低延迟的，因为您可以假设数据库服务器不被重载。没有必要向其抛出100多个并发查询。并不能让他们完成得更快。
• 文件系统:与数据库相同。

这些都是按典型案例分类的。所有这些也可以是相反的类别。

可以将同步和异步混合在同一个应用程序中。在它处于最佳位置时使用异步。

那么，为什么微软和实体框架团队要促进异步使用呢？下面是这个答案的主观部分:这可能是微软的内部政策。他们可能会预期EF在客户端应用程序中的使用(对于这些应用程序而言，异步是很好的)。或者，他们没有意识到异步数据库调用几乎总是浪费开发人员的时间而没有好处。大多数人没有意识到这一点，因为异步是当今的发展方向。

Answer 2

在ASP.NET上，您应该对任何与I/O相关的内容使用异步API，包括数据库访问和web服务调用。

使用async允许ASP.NET最大限度地利用线程池，从而带来非平凡的可伸缩性好处。

Answer 3

理想情况下，任何涉及等待一段时间的事情都应该异步完成。数据库查询通常必须调用远程服务器，发送查询，然后等待服务器响应结果。这使得它成为异步的主要候选对象，因为整个“等待服务器响应”部分是应用程序中无法考虑的变量。

在代码等待异步操作完成时，使用异步允许web服务器重用当前线程以字段其他web请求。当它完成时，线程将返回给您的应用程序以继续处理。如果运行同步，则在等待数据库或其他长时间运行的进程时，线程会死锁，并且web服务器的池不可用。如果这样做足够，web服务器可能会耗尽可用的线程，并且必须开始对进一步的请求进行排队。异步通过释放线程来缓解这一点，而线程只是在等待某些东西，从而增加了web服务器可以处理的潜在负载。