I have been reading more about C#’s new async keyword and support for it in .NET 4.5 and I’m looking for some help in thinking about it the ‘right way.’
My first thought was that I could improve the responsiveness of my sites by doing things I don’t need to wait for (like sending email, logging stuff, etc) asynchronously. This is something I’d just like to fire-and-forget and not make my client wait for.
But then I read about the new async versions of the SQL here and I get confused. Reading from the DB is something I have to wait for – I need the data – and I cannot proceed until it’s done. Does that mean I can’t use this?
Or, does it mean I’m making my request-handling more IIS-friendly by not blocking on the SQL calls?
The answer to these things is always “it depends.”
In your particular case, where you’re serving requests from IIS, you absolutely want to take advantage of this where you can, but you have to do it in a way that benefits IIS.
For example, when a client makes a request to an ASP.NET page (I assume this is the case, with question asking about IIS and .NET, that’s really the only option), the server has spun up a thread to handle your request. Of course, if there are many requests, then it’s going to take a lot of threads, possibly more than the server can handle, which means that some requests have to wait while others are being processed.
If in your thread (which is blocking other threads on the server) you have to wait for other work elsewhere, then it doesn’t make much sense to block the other threads while you wait for a response (from a web service, a database, etc). It would be better to give the server the thread back and then tell the server when you’re ready to do work again and offer up a response.
To this end, ASP.NET has mechanisms to let the server know that it can do other stuff while you’re waiting for a response.
ASP.NET WebForms has asynchronous pages (which I personally find a little convoluted) while ASP.NET MVC has asynchronous methods in version 4 (which fits into the Task-based asynchronous pattern much better).
That said, it should be noted that if you have other work that has to be done independently while waiting for the response, then there’s no reason to yield the thread back to the server, just do your work and when you get to the point where you can’t go any further, yield control back.
Whatever you do though, don’t wait on the result from the task; you’re blocking the server from using that thread for other uses while you’re doing nothing with it but waiting. This is probably the single biggest hindrance to scalability there is, and learning where you don’t need to hold onto server resources is one of the keys to writing highly scalable systems.