CODEWITHSUNDEEP
c#asp.net.netasync-awaitnancy
Jon
Jon

Reputation: 40062

When do you really need async on a web framework?

Async has become a buzzword in .net and MS have introduced it in Web API 2 so that more requests can be handled whilst others are waiting on IO to finish.

Whilst I can see the benefit of this, is it really a concern? A x64 architecture has 30000+ threads in the Thread Pool so unless you have that many concurrent users on your website is async really required? Even if you have that many concurrent users without caching I'm pretty sure SQL Server will fall over with that many requests?

Apart from it being shiny when is there a real need to have async routing on a web framework?

Upvotes: 12

Views: 2268

Answers (5)

Stephen Cleary
Stephen Cleary

Reputation: 457302

Many of the other answers here are coming from a UI (desktop/mobile app) perspective, not a web server perspective.

Async has become a buzzword in .net and MS have introduced it in Web API 2 so that more requests can be handled whilst others are waiting on IO to finish.

async and await were introduced in .NET 4.5 / VS 2012. However, ASP.NET has had asynchronous request capability since .NET 2.0 - a very long time ago. And there have been people using it.

What async and await bring to the table is asynchronous code that is easy to maintain.

Whilst I can see the benefit of this, is it really a concern?

The key benefit of async on the server is scalability. Simply put, async tasks scale far better than threads.

@Joshua's comment is key regarding the memory; a thread takes a significant amount of memory (and don't forget the kernel-mode stack which cannot be paged out), while an async request literally only takes a few hundred bytes.

There's also bursting to consider. The .NET threadpool has a limited injection rate, so unless you set your minWorkerThread count to a value much higher than you normally need, then when you get a burst of traffic some requests will 503 before .NET can spin up enough threads to handle them. async keeps your threads free (as much as possible) so it handles bursting traffic better.

A x64 architecture has 30000+ threads in the Thread Pool so unless you have that many concurrent users on your website is async really required?

@Joshua is again correct when he points out that you're probably thinking of a request queue limit (which defaults to 1000 for the IIS queue and 5000 for the ASP.NET request limit). It's important to note that once this queue is filled (during bursty traffic), new requests are rejected with 503.

Even if you have that many concurrent users without caching I'm pretty sure SQL Server will fall over with that many requests?

Ah, now that's another question entirely.

I'm giving a talk at ThatConference 2013 specifically on async servers. One part of that talk is situations where async doesn't help (my Twitter update).

There's an excellent blog post here that takes the position that asynchronous db calls are just not worth the effort. It's important to note the assumptions in this post:

  1. At the time that post was written, asynchronous web servers were difficult. These days we have async and more and more libraries are offering asynchronous APIs (e.g., Entity Framework).
  2. The architecture assumes a single web server with a single SQL Server backend. This was a very common setup traditionally, but is quickly changing today.

Where async servers really shine is when your backend can also scale. E.g., a web service, Azure SQL, NoSQL cluster, etc. Example: I'm writing an MVC/WebAPI server that uses Azure SQL and Storage for its backend (for all practical purposes, I can act like they have infinite scalability); in that case, I'm going to make my server async. In situations like this, you can scale your server 10x or more by using async.

But if you just have a single SQL Server backend (and have no plans to change to Azure SQL), then there's no point in making your web server async because you're limited by your backend anyway.

Upvotes: 11

Jalpesh Vadgama
Jalpesh Vadgama

Reputation: 14266

You need async in following scenarios

1) When you are performing a very long operation and you don't want to freeze your UI.

2) When you designed some task that needs to be completed in background.

For example, You are rendering images from database. But you don't want your page to be freeze at that time async is really helpful.

Upvotes: -2

Dmitrii Bychenko
Dmitrii Bychenko

Reputation: 186833

  1. When long operations can be efficiently executed in parallel. For instance, you have to execute two SQLs and load three pictures - do all five operations as async and await them all. In this case the overall time will be the longest duration of five operations, but not the sum of the durations.
  2. Pre-fetch. If you can predict (with good probability) what user will do (e.g. almost certainly, (s)he will want to see the details...) you may start preparing the next page (frame, window) while user's reading the previous.

Upvotes: 4

Piotr Perak
Piotr Perak

Reputation: 11118

where did you get 30000 from. i dont remember exactly but I think Asp.net uses 12 x number of cores threads.

Upvotes: 1

Maxim Zhukov
Maxim Zhukov

Reputation: 10140

I have to use async, when operation take too long time (upload, export, processing) and user have to know about progress.

Upvotes: 0

Related Questions