ASP.NET Asynchronous Methods Question

Question

I had a developer tell me recently that you should ALWAYS do database calls asynchronously. (Either using ThreadPool.QueueUserWorkItem or IAsyncResult and delegates)

His justification was this: IIS only has 24 (or so) threads that it can use for requests. When a user makes a request they get one of those threads. However, when you use asynchronous methods, you access Windows threads outside of IIS's scope. He said that when you use asynchronous methods this way, you are freeing up the initial thread to other users' requests, and transferring it over to a Windows thread (for that Thread's lifetime).

What do you think? Should all db calls be asynchronous?

Answer 1

Have you reason to believe you will hit such a bottleneck? This style of programming is hard you would have to have a seriously good reason to take this approach.

The limit is by default 20 worker threads but remember this is a per CPU core limit. If this limit became an issue in that ASP.NET became idle waiting for DB queries to complete why not just increase the thread limit a little (I'm not actually suggesting you do that since I don't in reality think it will be necessary).

Answer 2

There is a limited number of worker threads. These have to do with ASP.NET, not IIS (except in IIS7, where they're the same thing). It is true that database calls or any other call uses up one of these threads. In the case of ADO.NET calls, it is possible to write your pages as asynch pages, where no thread is used while the database operation is in progress.

You should not bother with this until or unless you actually have the problem.

Answer 3

If your site is so successful that you end up with a lack of threads to service requests, it would be cheaper, simpler, and less bug-prone to buy another webserver.

You might remind this developer that thread switching is not a free operation and in some instances might take longer than the db call.