C# 异步方法是提高性能还是只影响应用程序的可扩展性

我正在阅读关于EF core@的文档，作者提到了以下关于异步处理的内容：-

异步代码在运行时会引入少量开销 时间，但对于低流量情况，性能影响是 可忽略不计，而对于高流量情况，潜在的 性能改进是巨大的

---

但据我所知，使用异步代码不会提高性能，它只允许IIS处理更多请求，但无论使用同步还是异步处理，请求响应时间都不会改变。。。我的观点正确吗？

如果您将典型的IIS应用程序阶段分解为

从网络读取请求

反序列化请求

从数据库请求数据（EF调用）

使用缓存丰富数据

串行响应

向网络发送响应

1、3和6等待网络/SQL server完成。这些步骤占用了大部分请求时间（比如80%，而步骤2、4、5占用了剩余的20%）

如果步骤1、3、6是非异步的，则表示它们完成时有一个空闲进程线程在等待。服务器上可以有多少线程是有限制的，比如说10000个。由于CPU上下文开关的开销，以及与每个线程调用堆栈关联的内存，操作系统将无法支持更多。这意味着您不能让服务器同时处理超过10k个请求，即使其中80%的请求只会等待IO，其余20%的请求将竞争OS内核的调度

如果步骤1、3、6是异步的，则继续执行所需的调用变量将存储在一个特殊的任务继续数据结构中，该结构远小于完整的线程调用堆栈，操作系统没有重新调度10k线程的开销，IIS可以在线程数等于物理CPU内核的情况下运行，而这些线程占用100%的CPU全蒸汽处理完成的IO连续性。服务器吞吐量现在增加了4倍以上

---

若由于不需要创建任务，所以同步请求的数量永远不会超过服务器CPU内核的数量，那个么阻塞调用的工作速度比异步调用快，请将其完成情况排队。但这种情况很少发生。

你说得对了一半。异步代码将允许通过不阻塞I/O绑定代码上的线程来并发处理更多的请求，但由于创建异步状态机（通常表现为不可测量的额外延迟），它会带来少量（很可能是不可见的）开销。请记住，“性能”不仅仅意味着“延迟”。它也可能是http队列长度、内存、cpu、吞吐量等的一个因素。通常，在编写web API时，始终使用异步。