Why does the EF 6 tutorial use asynchronous calls?

Question

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?

I'm not sure what the benefit is for this style of development with ASP.NET MVC.

Can someone comment on this pattern, is this the new standard that MS is promoting?

Answer 1

In order to decide whether to go async or sync, compare the benefits and costs:

Async:

• 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)

Sync:

• Simpler code: await makes 99% of the cases (almost) as simple as synchronous code. That said, the 10+ async questions each day on Stack Overflow speak a different language. Edge cases arise when you deviate from the simple path. Also when using legacy libraries that, for example, require you to hand them a synchronous callback
• Less work for coding and debugging
• Profiler-friendly (You can profile the app or just pause the debugger and see what the app is doing right now. Not possible with async.)
• Interoperates perfectly with legacy code and libraries

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.

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.

Typical high-latency services (good cases for async):

• Web-services
• Waiting (e.g. sleep)
• Throttling (SemaphoreSlim, ...)
• Some cloud services (Azure)
• Long-running queries to the database (e.g. reporting or ETL)

Typical low-latency services (good cases for sync):

• Database calls: Most OLTP queries are low-latency because you can assume the database server to not be overloaded. No point in throwing 100s of concurrent queries at it. Doesn't make them complete any faster.
• File system: The same as databases.

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.

So why are Microsoft and the Entity Framework team promoting async usage? Here comes the subjective part of this answer: It might be Microsoft's 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 developers' time without benefits. Most people don't realize this because async is the way to go these days.