C# 多少异步/等待是可以的？

在我们的项目中，我们使用async/await几乎有3个目的（对于它们的所有方法）：

数据访问层：获取/更新数据库的地方（使用Dapper）

缓存（Redis）：读/写

NETMVC5控制器

问题是多少异步/等待是可以的。即使在读取或写入少量数据时也可以使用它们吗？缓存和控制器呢

---

备注：该项目有点特殊，在一天的几个小时内每秒可能有50000个请求。

根据我读到的一篇文章：

Async/await非常有助于避免阻塞，同时 在.NET应用程序中执行耗时的工作，但是 与运行异步方法相关的开销

当异步 工作需要很长时间，但值得记住

根据您的要求，即使在读取或写入少量数据时？。这似乎不是个好主意，因为已经过去了

以下是文章：

在这篇文章中，他使用了一个分析器来检查async/await的优化

引述：

尽管这种异步方法相对简单，但ANTS的性能 分析器显示，它导致900多个框架方法被运行 为了初始化它和它第一次执行的工作 它跑了

这里的问题是，你是否愿意接受这些最小的开销，并考虑到这些开销确实会堆积成一些可能有问题的东西

问题是多少异步/等待是可以的。甚至可以使用它们吗 读取或写入少量数据时？缓存和 控制器

对于I/O绑定的操作，应该使用async/await，如果数据量很小，这并不重要。更重要的是避免潜在的长时间运行的I/O绑定操作，主要是磁盘和网络调用。Asp.net的线程池大小有限，这些操作可能会阻止它。使用异步调用有助于应用程序更好地扩展，并允许处理更多并发请求

---

更多信息：

一根绳子有多长？要回答这个问题，必须看到您编写的任何代码，并且至少了解一点您的服务器环境。您是否仅对IO使用

async/await

？您是否在应该使用的位置使用

ConfigureAwait（false）

？你有没有做过分析和压力测试？您特别关注的是哪一个特定的代码段？我们设置了几个负载测试，模拟了大约10000个用户，甚至在简单的场景中，IIS8中都看到了排队的项目。记住，在服务器场景中，您仍然应该强烈地考虑I/O的“代码> ASYNC/<代码>，这是本质上不可预知的。大多数异步分析测试都假设后端100%响应，因此它们实际上只是测量异步开销。我想看到的是一个测试，它测量了这一点，然后是另一个测试，后端使用了1%的超时失败率-然后看看

async

是如何叠加的。