In this MSDN article (Chapter 6 — Improving ASP.NET Performance), it says the following:
"Avoid Asynchronous Calls Unless You Have Additional Parallel Work
Make asynchronous calls from your Web application only when your application has additional parallel work to perform while it waits for the completion of the asynchronous calls, and the work performed by the asynchronous call is not CPU bound. Internally, the asynchronous calls use a worker thread from the thread pool; in effect, you are using additional threads.
At the same time that you make asynchronous I/O calls, such as calling a Web method or performing file operations, the thread that makes the call is released so that it can perform additional work, such as making other asynchronous calls or performing other parallel tasks. You can then wait for completion of all of those tasks. Making several asynchronous calls that are not CPU bound and then letting them run simultaneously can improve throughput.
This is confusing to me. My understanding was that when you make an asynchronous I/O call that no thread is used while waiting, but that an IOCP is set with a reference to your callback method. Is it true that you should only use async calls when you have parallel work? My understanding was that for an ASP.NET Web Service, it is often a good idea to change a WebMethod Foo to BeginFoo/EndFoo when you will be calling an I/O bound operation and implement the whole thing asynchronously.
Can someone help me understand what is meant by “asynchronous calls use a worker thread from the thread pool; in effect, you are using additional threads”, and the difference between WorkerThreads and IO-threads?
It’s important to make a clear distinction process intensive operations (like calculating the one billionth prime number) and IO bound operations (like making a web service request).
A process intensive operation does require a thread to run on, so you are correct, using the ASP.NET asynchronous implementation has no benefit since you are still taking up an IIS thread.
IO bound operations are different, they use operating system IO completion ports and do not require a thread. In this case it can really help to use the ASP.NET asynchronous model because the request processing will only require a thread for a short time to execute the IO request, and then another thread for a short time to process the IO callback and return the response. This can really help scalability.
Jeff Prosise has a good post on the subject here:
http://www.wintellect.com/CS/blogs/jprosise/archive/2010/03/29/asynchronous-controllers-in-asp-net-mvc-2.aspx