在荷兰的Techdays期间,Steve Sanderson发表了关于C#5,ASP.NET MVC 4和异步Web的演讲.
他解释说,当请求需要很长时间才能完成时,线程池中的所有线程都会变忙,新请求必须等待.服务器无法处理负载,一切都变慢了.
然后,他展示了如何使用异步webrequests提高性能,因为然后将工作委托给另一个线程,并且线程池可以快速响应新的传入请求.他甚至演示了这一点,并显示50个并发请求首先占用了50*1,但异步行为总共只有1,2 s.
但看到这一点后,我仍然有一些问题.
为什么我们不能只使用更大的线程池？是不是使用async/await来启动另一个线程,然后从头开始增加线程池？它不像我们运行的服务器突然获得更多的线程或东西？
用户的请求仍在等待异步线程完成.如果池中的线程正在执行其他操作,那么"UI"线程如何保持忙碌状态？史蒂夫提到了一个关于'一个知道什么时候完成的智能内核'的东西.这是如何运作的？
我从这个问题中得到了 async/await-on-ASP.NET的各种好处.
我的理解是,异步与并行性不是一回事.因此,在Web服务器上,我想知道async/await给ASP.NET页面带来了多少好处.
是不是IIS + ASP.NET已经非常擅长为请求分配线程,如果onen页面忙于等待资源,服务器将只切换到处理另一个有工作要求的请求？
ASP.NET中可以使用有限数量的线程供ASP.NET使用 - 异步使用它们是否更有效？
正如Skeet先生在回答上述问题时指出的那样,我们不是在谈论阻止UI线程.我们已经是多线程的,并且在完成所有请求的任务之前无法完成Web响应,异步与否,对吗？
我猜它归结为:
对ASP.NET页面中的资源(例如文件或数据库请求)进行异步读取与阻止它有什么好处？