为什么EF 6教程使用异步调用? [英] Why does the EF 6 tutorial use asynchronous calls?
问题描述
有关如何将EF 6与MVC 5结合使用的最新EF教程似乎倾向于使用对数据库的异步调用，例如:
The latest EF tutorial that goes through how to use EF 6 with MVC 5 seems to lean towards using asych calls to the database like:
Department department = await db.Departments.FindAsync(id);
这是新的标准/最佳实践吗?
Is this the new standard/best practice?
我不确定使用ASP.NET MVC进行这种开发方式有什么好处.
I'm not sure what the benefit is for this style of development with ASP.NET MVC.
有人可以对此模式发表评论吗，这是MS正在推动的新标准吗?
Can someone comment on this pattern, is this the new standard that MS is promoting?
推荐答案
为了决定进行异步还是同步，请比较收益和成本:
In order to decide whether to go async or sync, compare the benefits and costs:
异步:
- 几乎永远不会用异步方式耗尽线程池(情况必须是极端的)
- 相当多的并发级别(并发请求和操作)
- 每次线程保存可节省1MB内存
-
SynchronizationContext可以确保安全的请求内并发
- 由于减少了OS调度开销，因此在高负载情况下可以通过低两位数的百分比提高吞吐量.也就是说，几乎没有生产应用程序处于高CPU负载下，因为如果它接近不可用(在负载高峰的情况下，该应用程序将开始丢弃请求)
- Almost never exhaust the thread-pool with async (the circumstances would have to be extreme)
- Pretty much arbitrary levels of concurrency (concurrent requests and operations)
- Saves 1MB of memory per thread save
- Safe intra-request concurrency thanks to the
SynchronizationContext - Can increase throughput by low double-digit percentages for high-load cases due to reducing OS scheduling overhead. That said, almost no production app is under high CPU load because if it was it was close to unavailability (in case of a load spike the app starts dropping requests)
同步:
- 简单代码:await使99％的情况(几乎)与同步代码一样简单.也就是说，每天在Stack Overflow上出现的10多个异步问题都使用不同的语言.当您偏离简单路径时，会出现边缘情况.同样，在使用旧版库时，例如，要求您向它们传递同步回调
- 减少编码和调试工作
- 对Profiler友好(您可以对应用程序进行配置文件，或者只是暂停调试器，然后立即查看应用程序在做什么.异步无法实现.)
- 与遗留代码和库完美互操作
如果要调用高延迟服务，请选择与ASP.NET异步. Web服务可能具有高延迟. OLTP数据库几乎总是低延迟的.
Choose async with ASP.NET if you are calling high-latency services. A web-service is likely to be high latency. An OLTP database is almost always low-latency.
如果您的应用程序受益于非常高的并发级别(100+)，请选择异步.大多数应用程序的级别都不高，或者它们的后端服务无法承受如此大的负载.使Web应用程序扩展规模毫无意义，但会使后端过载.呼叫链中的所有系统必须都必须从高度的并发中受益，以便异步才是有益的.
Choose async if your application benefits from very high levels of concurrency (100+). Most applications do not have such high levels, or their back-end services would not sustain such an amount of load. No point in making the web app scale but overload the back-end. All systems in the call chain must benefit from a high degree of concurrency in order for async to be beneficial.
典型的高延迟服务(异步的好案例):
- 网络服务
- 等待(例如睡眠)
- 节流(
SemaphoreSlim，...) - 一些云服务(Azure)
- 对数据库的长时间查询(例如报告或ETL)
- Web-services
- Waiting (e.g. sleep)
- Throttling (
SemaphoreSlim, ...) - Some cloud-services (Azure)
- Long-running queries to the database (e.g. reporting or ETL)
典型的低延迟服务(很好的同步条件):
- 数据库调用:大多数OLTP查询都是低延迟的，因为您可以假定数据库服务器不会过载.向它抛出100个并发查询毫无意义.并不能使它们更快地完成.
- 文件系统:与数据库相同.
这些按典型案例进行分类.所有这些也可以归为相反类别.
These are categorized by the typical case. All of these can be in the opposite category as well.
您可以在同一个应用中混合使用同步和异步功能.在异步应用程序处于最佳状态时使用它.
You can mix sync and async in the same app. Use async when it is at its sweet spot.
那么，为什么Microsoft和Entity Framework团队提倡异步使用?这是该答案的主观部分:可能是Microsoft内部政策.他们可能会预期客户端应用程序中的EF使用情况(对于异步应用程序而言，异步处理非常有用).或者，他们没有意识到异步数据库调用几乎总是浪费开发人员的时间而没有好处.多数人没有意识到这一点，因为异步是如今的方式.
So why are Microsoft and the Entity Framework team promoting async usage? Here comes the subjective part of this answer: It might be Microsoft internal policy. They might anticipate EF usage in client apps (for which async is great). Or, they don't realize that async database calls are pretty much almost always a waste of developer's time without benefits. Most people don't realize this because async is the way to go these days.
这篇关于为什么EF 6教程使用异步调用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
