Question

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?

Answer 1

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.