> Out of interest, how many people here actually use async methods? Excluding being forced to by a library. We use it almost exclusively. Because of the new as

> Out of interest, how many people here actually use async methods? Excluding being forced to by a library. We use it almost exclusively. Because of the new async/await syntax it is (almost) as easy to write and get correct as non-async code. Async/await makes an entire class of problems go away (and, ok, swaps it for a class of easier-to-solve problems). In a web application you always need to consider how your application will be impacted by the traffic. Are all of your requests served within 50 milliseconds? Fine, then you do not need async. Do your handlers ever call out to an external site or even a local database where it may block for more than 50 milliseconds? Then you need to consider what happens when almost all of the requests block at at same time: A colossal waste of resources. Traditionally we have handled this by increasing the number of threads we allow the server to use for serving requests. However, threads are expensive in overhead (memory, cpu for context switching) and it affects the footprint of your application, and with that how dense you can pack virtual servers. Enter async: When a request blocks on an external call (to an external site, database etc), the request relinquishes the thread which will be used to serve other requests. What's more: The more you use async/await, the more the application will auto-scale. It will only start new threads when there's actual work to be done rather than when there's waiting to be done.