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