Asynchronous Controllers at ASP.NET 4 make sense?

Question

Asp.net 2 have 12 threads by default

Now Asp.Net 4 have 5000. We still need async controllers?

Answer 1

We still need async controllers?

Yes. Async controllers are useful in situations where you have lengthy operations such as network calls and you don't want to monopolize worker threads for them. The fact that there are 5000 worker threads by default doesn't mean that you have to waste them. Is it because you are a millionaire that you are giving away your money? No.

Obviously if you don't use async controllers correctly they will do more harm than good.

Answer 2

MVC 4/Dev11 makes Async controllers more appealing than previous versions. Add to that WebAPI making it easy to create web services. Start of Levi's comments so they won't be missed (under @Darin Dimitrov's excellent answer)

Expanding on Darin's answer a bit - asynchronous I/O operations (which is what AsyncController is intended for) operate using IOCP, not ThreadPool threads. This is important, as each ThreadPool thread has an associated 1 MB stack (plus other overhead), so if you're using 5000 ThreadPool threads, you're automatically losing 5 GB of memory just due to overhead! IOCP continuations have nowhere near as much overhead, so it's possible to juggle greater numbers of them at any given time. ThreadPool threads are pooled and removed when no longer needed - so you're only taking the hit for threads which are currently active. But if you're doing a lot of concurrent CPU-bound work with ThreadPool, you're very rapidly going to start hitting memory issues. This is precisely one of the reasons the C# / VB teams released the Async CTP a few months ago - to try to solve this issue.

Async for Web service often makes sense - see Should my database calls be Asynchronous Part II

For database applications using async operations to reduce the number of blocked threads on the web server is almost always a complete waste of time. A small web server can easily handle way more simultaneous blocking requests than your database back-end can process concurrently. Instead make sure your service calls are cheap at the database, and limit the number of concurrently executing requests to a number that you have tested to work correctly and maximize overall transaction throughput

See Should my database calls be Asynchronous?

Answer 3

4 or 5000, it doesn't matter, it is just a setting. You can set it to 1 billion if you want to, that won't make your application more scalabe. In the end your machine only has 4 cores (or 8 or 2, but not 5000). Always keep in mind that you can only ever have as many threads running at the same time that the number of cores. Every thread you have in excess to your number of cores is just overhead. It will create more context switches, consume CPU and occupy more memory.

IO (database access, web service, file access...) is not taking up any CPU. If you do it synchronously, it will block a thread for the length of the operation. If you have a lengthy operation (5 seconds), and a load of 1,000 request per second, you will be permanently blocking 5,000 threads. So you are already starving the thread pool (with a setting of 5,000). But what is worse is that you will be trashing your maching with context switches. If you do it asynchronously, no thread will be blocked, no resource is taken, and you have no limit on the number of concurrent IO you can do.

Adding more threads in the thread pool is a quick and dirty hack when you can't afford rewriting your application using asynchronous IO. It is not a clean solution.