我的理解是,异步与并行性不是一回事.因此,在Web服务器上,我想知道async / await给ASP.NET页面带来了多少好处.
IIS ASP.NET是否已经非常擅长为请求分配线程,如果onen页面忙于等待资源,服务器将只切换到处理另一个有工作要求的请求？
ASP.NET中可以使用有限数量的线程供ASP.NET使用 – 异步使用它们是否更有效？
正如Skeet先生在回答上述问题时指出的那样,我们不是在谈论阻止UI线程.我们已经是多线程的,并且在完成所有请求的任务之前无法完成Web响应,异步与否,对吗？
我猜它归结为：
解决方法
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?
是的,因为等待某事时,该请求的线程会立即返回到池中.
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?
那是正确的.服务器方案中的异步就是消除线程池上的压力.
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?
绝对！
如果阻止文件/服务调用/ db请求,则该线程将用于该操作的持续时间.如果等待文件/服务调用/ db请求,则该线程立即返回到线程池.
一个(真的很酷！)结果是你可以有一个正在进行的请求,虽然它是(a)等待一些操作,但没有线程服务该请求！零线程并发,如果你愿意的话.
当操作完成时,该方法在等待 – 从线程池中的(可能不同的)线程上恢复.
总结：异步比线程更好,所以在服务器端肯定有一个好处.
更多信息：我自己的intro to async post和this awesome video.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
