views:

79

answers:

2

I'm just wondering, if I have an ASP.net Web Application, either WebForms or MVC, is there any situation where doing stuff asynchronously would make sense?

The Web Server already handles threading for me in that it spins up multiple threads to handle requests, and most request processing is rather simple and straight forward.

I see some use for when stuff truly is a) expensive and b) can be parallelized. but these are the minority cases (at least from what I've encountered).

Is there any gain from async in the simple "Read some input, do some CRUD, display some output" scenario?

+3  A: 

If a page is making a request to an external web service on every request, then using the asynchronous BCL APIs to fetch data from the web service will help free up resources on the server. This is because Windows can make a distinction between a managed ASP thread that is waiting for stuff (asynchronous web service call) and a managed ASP thread that is doing stuff (synchronous web service call). These asynchronous calls may end up as I/O Completion Ports behind the scenes, freeing ASP from essentially all of the burdens. This can result in the web site being able to handle more simultaneous requests. Specifically, when an ASP thread is waiting for a callback from an asynchronous operation, ASP may decide to reuse that thread to serve other requests in the meantime.

The synchronous BCL way to invoke external resources is the Get(), Read(), EndRead() etc family of methods. Their asynchronous counterpart is the BeginGet(), EndGet(), BeginRead(), EndRead() etc family of methods.

If you have a page that does two things simultaneously, and both are essentially wait for external data type operations, then the asynchronous BCL APIs will enable parallellism automatically. If they are calculate pi type operations, then you may want to use the parallell BCL APIs instead.

bzlm
That sounds interesting - how would I wait? Just Thread.Sleep()?
Michael Stum
@Michael You never need to wait for anything explicitly! If you use synchronous APIs, they will make you wait automatically. If you use asynchronous APIs, waiting will be done automatically via callbacks. I've updated my answer.
bzlm
+2  A: 

Here's one example when you will clearly gain from an async call: imagine that in order to render a page you need to aggregate information coming from different web services (or database calls) where each being independent and resulting in a network call. In this case the async pattern is very good because you have IO bound operations for which IO Completion Ports will be used and while waiting for the response you won't monopolize worker threads. While the operations are running no thread will be consumed on the server side.

If you have many CPU bound operations than async pattern will not bring much benefit because while you free the request worker thread from performing the operation, another thread will be consumed to do calculations.

I find this article a very useful reference.

Darin Dimitrov