我一直在阅读有关 C# 的新 async 关键字以及 .NET 4.5 中对它的支持的更多信息，我正在寻求一些帮助来以“正确的方式”思考它。
我的第一个想法是，我可以通过异步执行不需要等待的事情（例如发送电子邮件、记录内容等）来提高网站的响应能力。这是我只想一劳永逸的事情，而不是让我的客户等待。
但后来我在这里读到了新的异步 SQL 版本，我感到很困惑。从数据库读取是我必须等待的——我需要数据——在完成之前我无法继续。这是否意味着我不能使用它？
或者，这是否意味着我通过不阻止 SQL 调用使我的请求处理对 IIS 更加友好？
这些事情的答案总是“视情况而定”。
在您的特定情况下，您正在为来自 IIS 的请求提供服务，您绝对希望尽可能利用这一点，但您必须以有利于 IIS 的方式进行操作。
例如，当客户端向 ASP.NET 页面发出请求时（我假设是这种情况，询问有关 IIS 和 .NET 的问题，这确实是唯一的选择），服务器已启动一个线程来处理您的请求. 当然，如果有很多请求，那么它会占用很多线程，可能超出服务器的处理能力，这意味着一些请求必须等待而其他请求正在处理。
如果在您的线程中（阻塞服务器上的其他线程）您必须在其他地方等待其他工作，那么在等待响应（来自 Web 服务、数据库）时阻塞其他线程没有多大意义， ETC）。最好将线程返回给服务器，然后在您准备好再次工作并提供响应时告诉服务器。
为此，ASP.NET 具有让服务器知道它可以在您等待响应时执行其他操作的机制。
ASP.NET WebForms 有异步页面（我个人觉得有点复杂），而 ASP.NET MVC在版本 4 中有异步方法（更适合基于任务的异步模式）。
也就是说，应该注意的是，如果您在等待响应时必须独立完成其他工作，那么没有理由将线程返回给服务器，只需完成您的工作，当您到达你不能再往前走了，让出控制权回来。
不管你做什么，不要等待任务的结果；您正在阻止服务器将该线程用于其他用途，而您除了等待之外什么都不做。这可能是可扩展性的最大障碍，而了解您不需要占用服务器资源的地方是编写高度可扩展系统的关键之一。