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

Question

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

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

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

池中可供 ASP.NET 使用的线程数量有限——异步使用它们是否更有效？

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

我想归结起来是这样的:

在 ASP.NET 页面中异步读取资源(比如文件或数据库请求)与阻塞它有什么好处吗？

Answer 1

if one page is busy waiting for a resource the server will just switch to processing another request that has work to do?

我不这么认为。如果是这种情况，我会感到非常惊讶。这在理论上是可能的，但非常复杂。

There are a limited number of threads in the pool for ASP.NET to use - does async use them any more effectively?

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

We're already multi-threaded and the web response can't be completed until all the request's tasks are done, async or not, right?

那是正确的。 async在服务器场景中，一切都是为了消除线程池的压力。

Is there any benefit to an async read of a resource (say a file or DB request) in an ASP.NET page vs. blocking on it?

绝对地!

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

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

操作完成后，该方法会在 await 之后恢复- 在来自线程池的(可能不同的)线程上。

总之: async比线程更好地扩展，因此在服务器端肯定有好处。

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