Why does the EF 6 tutorial use asynchronous calls?

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?

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 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.

On ASP.NET, you should use asynchronous APIs for anything I/O-related, including database access and web service calls.

Using async allows ASP.NET to make maximum use of the thread pool, resulting in non-trivial scalability benefits.

Ideally, anything that involves a period of waiting should be done asynchronously. A database query typically must call out to a remote server, send the query, and then wait for the server to respond with the results. That makes it a prime candidate for async as that whole "wait for the server to respond" part is a variable you can't account for in your application.

Using async allows the web server to reuse the current thread to field other web requests while your code is waiting for the async operation to complete. When it completes, a thread is given back to your application to continue processing. If you run sync, then while you're waiting for the database or whatever other long running process, the thread deadlocks and is not available to the web server's pool. If you do this enough, the web server can potentially run out of available threads and must begin queuing further requests. Async mitigates this by freeing up threads when they're just hanging around waiting on something, increasing the potential load that your web server can handle.