ASP.NET 异步/等待第 2 部分

Posted 2023-02-19

【中文标题】ASP.NET 异步/等待第 2 部分

【英文标题】：ASP.NET async/await part 2

【发布时间】：2012-07-31 10:54:56

【问题描述】：

我有一个来自 this question 的 async/await-on-ASP.NET 的好处的变体。

我的理解是异步与并行不是一回事。所以，在 Web 服务器上，我想知道 async/await 给 ASP.NET 页面带来了多少好处。

IIS+ASP.NET 不是已经非常擅长为请求分配线程了吗？如果一个页面忙于等待资源，服务器就会切换到处理另一个有工作要做的请求？

池中可供 ASP.NET 使用的线程数量有限 - async 是否更有效地使用它们？

正如 Skeet 先生在回答上述问题时指出的那样，我们并不是在谈论阻塞 UI 线程。我们已经是多线程的，在所有请求的任务都完成之前无法完成 Web 响应，无论是否异步，对吧？

我想归根结底是这样的：

在 ASP.NET 页面中异步读取资源（例如文件或 DB 请求）与阻塞它有什么好处？

【问题讨论】：

您是否真的阅读过您提到的 Jon Skeet 的回答？他确实解释了在 ASP.NET 中使用 async 的好处。

@svick：感谢您的阅读。是的，我读了乔恩的回答，但在很多情况下，他说“这取决于”，我想这是他可以给出的唯一答案。我想了解 async/await 在大容量 Web 服务器上的线程含义。

【参考方案1】：

如果一个页面忙于等待资源，服务器将切换到处理另一个有工作要做的请求？

我不这么认为。如果是这样的话，我会非常感到惊讶。理论上可行，但非常复杂。

池中可供 ASP.NET 使用的线程数量有限 - async 是否更有效地使用它们？

是的，因为当您await 某事时，该请求的线程会立即返回到池中。

我们已经是多线程的了，直到所有请求的任务都完成后才能完成网络响应，无论是否异步，对吧？

没错。服务器场景中的async 就是为了消除线程池的压力。

在 ASP.NET 页面中异步读取资源（例如文件或 DB 请求）与阻塞它有什么好处？

绝对！

如果您阻塞文件/服务调用/db 请求，则该线程将在该操作期间使用。如果您await 一个文件/服务调用/db 请求，那么该线程会立即返回到线程池。

这样做的一个（真的很酷！）结果是您可以有一个正在进行的请求，并且当它（a）等待某个操作时，没有 线程为该请求提供服务！零线程并发，如果你愿意的话。

当操作完成时，该方法在await 之后恢复 - 在线程池中的一个（可能不同的）线程上。

结论：async 的可扩展性比线程好，因此在服务器端肯定有好处。

更多信息：我自己的intro to async post 和this awesome video。

【讨论】：

从您最近发布的answer 中受益：“如果您正在谈论具有单个数据库后端的 ASP.NET MVC，那么您（几乎可以肯定）不会得到任何可伸缩性受益于async。这是因为 IIS 可以处理比 SQL 服务器（或其他经典 RDBMS）的单个实例更多的并发请求。但是，如果您的后端更现代 - SQL 服务器集群、Azure SQL、NoSQL，等等 - 您的后端可以扩展，而您的可扩展性瓶颈是 IIS，那么您可以从 async 获得可扩展性优势。”