我继承了一个MVC web应用程序，它使用ADO.NET之上的Dapper在Controller操作方法中进行DB调用。这都是非常标准的东西——没有多少控制器是async，所有的数据库调用都通过完全同步的repository。
我正在将其转移到Azure，并将SQL Azure用于数据库后端。我预计负载会相当标准，比如每分钟500-1000次点击。
所以，我想知道，我是否应该仔细阅读这些代码，使我所有的数据库调用异步，这样我就可以在控制器中await了。这样做会释放我的线程来处理其他请求，但我想知道我是否会注意到任何改进。
我知道，以前有人注意到，如果你有一个数据库服务器（就像我一样），那么你不会看到太多改进，因为瓶颈都在数据库上。然而，SQL Azure是一个略有不同的野兽，而Azure表示
良好的实践要求您只使用异步技术来访问Azure服务，如SQL数据库源
那么，这值得付出努力吗？
坦率地说，这里不可能给出任何明确的答案。正如Azure所说，最佳实践是将异步与I/O绑定操作一起使用，包括查询远程数据库之类的操作。如果您是从零开始启动这个应用程序，那么今天，我肯定会告诉您在数据库调用中使用async。
然而，这并不是一个新的应用程序，在这一点上，使用异步似乎需要相当多的操作。根据你的工作量，你可能最终看不到工作的任何收获，但你也可能看到巨大的收获。我的建议是从小处着手。我会挑选一些运行时间更长的查询或严重依赖数据库的操作，并从中开始。通过这种方式，您可以引入一点异步，并自行判断是否值得进一步研究。而且，由于这些可能是应用程序的瓶颈，无论如何，您可以在最重要的地方获得异步的好处。
您添加的任何新功能从一开始就应该是异步的，然后，只要您有时间和意愿，就可以慢慢地转换整个应用程序。
我所学到的（并通过测试进行了验证）是，您不会看到相对较长的SQL调用有很大的改进。但是，您将看到对并发短SQL和非SQL相关响应的改进。这是因为初始化线程需要花费大量的成本。因此，重用等待SQL的休眠线程确实可以提高性能。
使用async还可以保护您不超过IIS中的"每处理器线程数限制"设置。当这种情况发生时，您的请求会被排队。我们已经尝试过增加默认值25。这确实提高了高负载下的性能，但通过将所有控制器更改为异步，我们看到了更好的改进。
所以我想你的问题的答案是，这取决于情况。如果除了SQL调用之外还有大量并发请求，那么这些并发请求的响应时间应该会有显著的改进。但是，您不会看到相对较长的SQL调用有多大改进。