async actions help best when the actions does some I\O operations to DB or some network bound calls where the thread that processes the request will be stalled before it gets answer from the DB or network bound call which you just invoked. It's best you use await with them and it will really improve the responsiveness of your application (because less ASP input\output threads will be stalled while waiting for the DB or any other operation like that). In all my applications whenever many calls to DB very necessary I've always wrapped them in awaiatable method and called that with await keyword.

在ASP中处处使用异步操作好吗?净MVC吗?

在任何可以使用异步方法的地方这样做都是很好的，特别是当你在工作进程级别有性能问题时，这发生在大量数据和计算操作中。否则，不需要，因为单元测试将需要强制转换。

关于可等待方法:我是否应该使用async/await关键字当我 想查询一个数据库(通过EF/NHibernate/其他ORM)?

是的，最好对任何DB操作使用异步，以尽可能避免工作进程级别的性能问题。 注意，EF已经为大多数操作创建了许多异步选项，例如:

.ToListAsync()
.FirstOrDefaultAsync()
.SaveChangesAsync()
.FindAsync()

我可以使用await关键字查询数据库多少次 异步在一个单一的动作方法?

前途无量

async actions help best when the actions does some I\O operations to DB or some network bound calls where the thread that processes the request will be stalled before it gets answer from the DB or network bound call which you just invoked. It's best you use await with them and it will really improve the responsiveness of your application (because less ASP input\output threads will be stalled while waiting for the DB or any other operation like that). In all my applications whenever many calls to DB very necessary I've always wrapped them in awaiatable method and called that with await keyword.

As you know, MVC supports asynchronous controllers and you should take advantage of it. In case your Controller, performs a lengthy operation, (it might be a disk based I/o or a network call to another remote service), if the request is handled in synchronous manner, the IIS thread is busy the whole time. As a result, the thread is just waiting for the lengthy operation to complete. It can be better utilized by serving other requests while the operation requested in first is under progress. This will help in serving more concurrent requests. Your webservice will be highly scalable and will not easily run into C10k problem. It is a good idea to use async/await for db queries. and yes you can use them as many number of times as you deem fit.

看看这里的优秀建议。

我的经验是，今天很多开发人员使用async/await作为控制器的默认设置。

我的建议是，只有在你知道它对你有帮助的时候才使用它。

原因是，正如Stephen Cleary和其他人已经提到的，它会引入性能问题，而不是解决问题，并且它只会在特定的场景中帮助您:

高流量控制器 可伸缩的后端

当一个动作必须执行几个独立的长时间运行的操作时，异步动作方法非常有用。

AsyncController类的典型用途是长时间运行的Web 服务调用。

我的数据库调用应该是异步的吗?

IIS线程池通常可以处理比数据库服务器更多的并发阻塞请求。如果数据库是瓶颈，异步调用将不会加快数据库响应。在没有节流机制的情况下，通过使用异步调用将更多的工作高效地分配到不堪重负的数据库服务器，只会将更多的负担转移到数据库。如果您的DB是瓶颈，异步调用将不是灵丹妙药。

你应该看一下第一和第二篇参考文献

源自@PanagiotisKanavos评论:

此外，异步并不意味着并行。异步执行释放 有价值的线程池线程从阻塞外部资源，为 没有复杂性或性能成本。这意味着同一台IIS机器可以 处理更多并发请求，并不是说它会运行得更快。 您还应该考虑阻塞调用以 cpu密集型spinwait。在压力大的时候，阻止电话会 导致不断升级的延迟和应用程序池回收。异步调用 避免这种情况