Only implement an ASP.NET WebMethod asynchronously if you can parallelize?

Answer 1

Hi There, have a look at this one http://msdn.microsoft.com/en-us/library/ms979194.aspx as it should show you how to monitor thread pool. Hope this helps... Regards, Andy

Answer 2

Each request to an ASP.NET application is run in its own thread from a pool of threads available to the w3wp worker process. When you run an asynchronous call you are, in effect, making a separate request to the ASP.NET application and using another of the threads available in the pool. The pool is a fixed size depending upon your server configuration and hardware limitations, it represents the maximum number of request your server can fulfill at any one time.

Asynchronous calls are used primarily when multiple "heavy" operations are necessary in order to decrease the time it takes to return a page to the client and in some cases to increase overall thread availability.

Think of it this way, you request a webpage that has four stock graphs (1 thread in use). The page makes a request to the first stock service (1 new thread + 1 old thread = 2 threads in use.) The page receives the results (1 thread closed, 1 thread in use). The page makes a request to the second stock service (1 new thread + 1 old thread = 2 threads in use.) And so on. Assuming each stock service takes four seconds to respond, you are tying up 2 threads at 16 seconds each for a total processing time of 32 seconds (not to mention the fact that it takes 16 seconds for the clients page to load.) These numbers are all fake of course but are intended to illustrate the point.

Now, in an asynchronous implementation you request a webpage that has four stock graphs (1 thread in use.) The page makes four requests to stock services (1 old thread + 4 new threads = 5 threads in use) Assuming each stock service takes four seconds to respond, you are tying up 5 threads at 4 seconds each for a total processing time of 20 seconds AND the client received the page in 4 seconds. You reduced the overall cost of the operations because your primary thread, which cannot be released until the client page is served, was in use for a shorter period of time.

Finally, none of this has much to do with I/O threads. Calling an asynchrounous web method because it contains I/O operations will not necessarily provide you with any benefit unless you have significant processing to complete while you wait for the results. Or, in the words of the article, "Avoid Asynchronous Calls Unless You Have Additional Parallel Work."