有没有理由*不*在每个应用程序中实现异步ASP.NET网页？

Question

关于MSDN上的异步ASP.NET网页文章.

长期运行的页面或高服务器负载的优点是显而易见的.因此,如果项目中您认为需求可能在某个地方可能很高,那么当使用率增长时,是否有任何理由不在每个Web应用程序中实现异步ASP.NET作为标准？这种方法有什么缺点吗？

次要问题:在不同的网络应用情况下,是否有任何真实的研究/示例在哪些优势开始出现？或者只是吮吸它看到的问题？

Answer 1

从您自己的链接:

只有I/O绑定操作才能成为异步控制器类上的异步操作方法.I/O绑定操作是一种不依赖于本地CPU完成的操作.当I/O绑定操作处于活动状态时,CPU只等待从外部存储(数据库或远程服务)处理(即下载)数据.I/O绑定操作与CPU绑定操作形成对比,其中任务的完成取决于CPU的活动.

异步页面不是免费的,它们确实需要付出代价.当您的页面对服务进行外部调用或执行一些长时间运行的非CPU绑定操作时,它们通常都很好.否则,您可能会瘫痪CPU,使您在进行异步之前遇到更糟糕的情况.

当您从应用程序的线程池中吃掉一个执行非CPU密集型工作的线程(等待长时间运行的服务的响应)时,我们的想法是使用异步.这样,您的应用程序可以继续处理请求,并且不会开始排队新请求,从而慢慢消耗应用程序的响应能力.

当/不使用异步页面时,这是另一个信息链接.

编辑

至于什么被认为是"长跑",你面对的是"这取决于"的糟糕答案.要解决这个问题,您需要对应用程序进行概要分析,查看有多少"长时间运行"的请求导致后续请求被IIS排队,而不是处理.这个决定归结为处于这样一种情况:付出代价高昂的环境转换费用低于你将要做的回报.如果您的瓶颈是导致传入请求被阻止的某个页面或服务,那么开始考虑异步工作可能是个好主意.但是,您可能也在请求中做了太多工作,这可能是您需要重构代码的"代码味道".

最后,这取决于.

这是MSDN的一个例外.

通常,在满足以下条件时使用异步管道:

• 这些操作是网络绑定的或I/O绑定的,而不是CPU绑定的.

• 测试表明,阻塞操作是站点性能的瓶颈,IIS可以通过对这些阻塞调用使用异步操作方法来为更多请求提供服务.

• 并行性比代码的简单性更重要.

• 您希望提供一种机制,允许用户取消长时间运行的请求.

虽然链接是关于MVC的,但这个想法也适用于其他类型的ASP.NET.