By public static


2014-08-01 18:55:47 8 Comments

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?

3 comments

@usr 2014-08-01 19:22:45

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.

@public static 2014-08-01 19:25:30

How does this effect unit of work? In EF 4/5 I was using unit of work pattern but in EF 6 it seems the article is saying you don't really need it.

@usr 2014-08-01 19:28:15

@valid_where_void this does not affect "unit of work" at all. Thanks to await you can pretty much make every algorithm you have async with minimal structural changes. If you post the article link I can comment specifically.

@Chris Pratt 2014-08-01 19:29:21

@valid_where_void: using the unit of work pattern with EF has nothing to do with async vs sync. It's more that there's a new version of EF and with it new understanding and recommendations for patterns and processes. Unit of work / repository with EF, was never a good idea, the tutorials are just finally being updated to reflect that.

@Chris Pratt 2014-08-01 19:31:43

@usr: Two things: 1) It's not accurate to say "never" exhaust thread-pool. You very much can still exhaust the thread pool even if you do everything async. It just gives you a higher ceiling than sync. 2) Maybe "simpler code" was true as a benefit of sync pre-.NET 4.5, but with async/await it's almost stupidly simple to do async and doesn't really complicate the code at all.

@usr 2014-08-01 19:35:56

@ChrisPratt I edited. Regarding simpler code: True for 99% of the cases. 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.

@Greg 2015-03-09 20:31:06

One major push by Microsoft towards Async is for Windows 8 applications on mobile devices, where that model maximizes UI responsiveness while minimizing battery usage. But those concerns are generally not in the thoughts of most web developers. That being said, async does come into play for long running items that only do work on rare events (signal R); running different pieces in parallel, or long running network/db requests.

@Greg 2015-03-09 20:31:08

@Chris Pratt 2014-08-01 19:04:45

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.

@Wouter de Kort 2014-08-01 19:08:18

Although your answer is a good one, you may want to point out that not 'anything that can take a while should be done asynchronously'. In a web application you should execute I/O tasks async, but not CPU bound work. Only if you want to run things in parallel you can split CPU bound work but you should still measure performance to make sure you're not using more threads than is worth it.

@Chris Pratt 2014-08-01 19:15:19

True, you can't async CPU-bound work because it needs the thread to complete the work. However, I was trying to keep the answer simplistic. CPU-bound pretty much excludes "taking awhile" in most scenarios except complex scientific or financial analysis, which is even more rare in a web scenario (the web application almost assuredly won't being doing the complex analysis itself, but rather some service that it would interact with). But, your point is valid, nevertheless.

@public static 2014-08-01 19:15:41

So did MS re-write all its libraries to make them truly asynchronous? Or is it just wrapping it in a asych block but under the covers it is all synchronous.

@Chris Pratt 2014-08-01 19:17:34

I don't know about all. I actually just butted up with the rather annoying fact that you can't do async action filters still in MVC5. But, yes, ever since .NET 4.5 introduced the async/await combo, making the core libraries async-capable has been a priority.

@Stephen Cleary 2014-08-01 19:26:44

@ChrisPratt: Unfortunately true. However, async filters are supported on WebApi today and will be supported on MVC on ASP.NET vNext.

@Stephen Cleary 2014-08-01 19:00:27

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.

@usr 2014-08-01 19:04:33

Non-trivial scalability benefits, in case the database can handle hundreds of concurrent requests.

@Wouter de Kort 2014-08-01 19:06:44

@usr as Stephen mentions, the scaling is in the thread pool. Even if not all pages of your website depend on the database, using async calls will free up threads to serve requests. The scaling benefits are definitely non-trivial. If you want to support hundred thousands of requests, of course you need to look at your database but that's not what he means in this situation.

@usr 2014-08-01 19:10:37

The thread-pool only limits scalability when we go into the hundreds of concurrent operations. You can only achieve meaningfully more throughput going async if the thread-pool would have been exhausted otherwise. I understand the benefits of async, but they do not come for free. You pay with development cost for them. It would be irrational to go async in every situation.

@public static 2014-08-01 19:14:35

@usr that is what sparked this question, it is a 'how to' tutorial and they are pushing asych down everyone's throats. I wanted to know if this is considered best practise or is it over-optimization. We have been doing sych. calls for years and for 99% of apps it is never an issue.

@Stephen Cleary 2014-08-01 19:24:14

@usr: Modern async is practically as easy as sync. And it does bring benefits even before the thread pool is exhausted: in particular, async scales faster than the thread pool can by itself due to its limited injection rate. So it's great for bursting traffic.

@Chris Pratt 2014-08-01 19:24:53

@usr: while true that if you're getting like 10 hits per month on your site, async is indeed probably overkill, the idea is to integrate scalability from the start. Async isn't free, but it's also not that costly. And, the millisecond here or there that it may take longer to load a page will more than pay for itself when your site suddenly goes under heavy load unexpectedly (the "Digg-effect") and starts falling down because you did everything sync.

@usr 2014-08-01 19:26:52

@StephenCleary I had a great experience with just increasing thread-pool limits to mad levels (especially the minimum counts). This was for a legacy app. I would have used await had it been available at the time. We were calling a web service taking 10s for some high-frequency calls. Sweet spot for async, and still the thread-pool could keep up.

@usr 2014-08-01 19:29:57

@ChrisPratt when Digg puts load on you, your backend will limit your throughput. Make your web app ready to serve 1000 concurrent requests but it doesn't help a database which has only a few CPU cores. They will just queue up and the site falls down. Async does not help here.

@Stephen Cleary 2014-08-01 19:41:38

@usr: You're making the classic case against async DB calls on ASP.NET. That argument made a lot of sense when async was hard and there was a single SQL Server backend. These days, async is easy and backends more often than not are Azure SQL or scalable NoSQL, and that argument doesn't hold up as well. (It's still a valid argument; it's just a lot weaker these days).

@usr 2014-08-01 19:42:29

@StephenCleary true. For those cases I acknowledge the usefulness of async. Will edit that into my answer.

Related Questions

Sponsored Content

11 Answered Questions

[SOLVED] What does the [Flags] Enum Attribute mean in C#?

  • 2008-08-12 04:09:16
  • Brian Leahy
  • 456819 View
  • 1375 Score
  • 11 Answer
  • Tags:   c# enums flags

26 Answered Questions

[SOLVED] Why not inherit from List<T>?

9 Answered Questions

[SOLVED] Call one constructor from another

  • 2010-10-24 16:06:31
  • Avi
  • 432421 View
  • 925 Score
  • 9 Answer
  • Tags:   c# constructor

14 Answered Questions

[SOLVED] How to call asynchronous method from synchronous method in C#?

  • 2012-02-18 17:49:28
  • Tower
  • 533940 View
  • 744 Score
  • 14 Answer
  • Tags:   c# async-await

12 Answered Questions

[SOLVED] Why is it important to override GetHashCode when Equals method is overridden?

  • 2008-12-16 13:41:18
  • David Basarab
  • 351676 View
  • 1365 Score
  • 12 Answer
  • Tags:   c# overriding hashcode

10 Answered Questions

[SOLVED] Calling the base constructor in C#

19 Answered Questions

[SOLVED] Why is Dictionary preferred over Hashtable in C#?

17 Answered Questions

[SOLVED] Virtual member call in a constructor

4 Answered Questions

3 Answered Questions

[SOLVED] ASP.NET MVC modal dialog/popup best practice

Sponsored Content