2

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

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

第二个问题：在不同的网络应用情况下，是否有任何现实世界的研究/例子说明优势开始出现的地方？或者这只是吸吮它然后看看的问题？

4

1 回答 1

7

从您自己的链接：

只有 I/O-bound 操作是成为异步控制器类上的异步操作方法的良好候选者。I/O-bound 操作是不依赖本地 CPU 完成的操作。当 I/O 绑定操作处于活动状态时，CPU 只是等待从外部存储（数据库或远程服务）处理（即下载）数据。I/O-bound 操作与 CPU-bound 操作相反，后者任务的完成取决于 CPU 的活动。

异步页面不是免费的，它们是有代价的。当您的页面对服务进行外部调用或执行一些长时间运行的、非 CPU 绑定的操作时，它们通常很好。否则，您可能会破坏 CPU，从而使您处于异步之前的更糟情况。

这个想法是在您从应用程序的线程池中占用一个线程来执行非 CPU 密集型工作（等待来自长时间运行的服务的响应）时使用异步。这样，您的应用程序可以继续处理请求，而不会开始排队新的请求，从而慢慢耗尽您的应用程序的响应能力。

这是另一个链接，其中包含何时/何时不使用异步页面的信息。

编辑

至于什么被认为是“长期运行”，您将面临“这取决于”的糟糕答案。要弄清楚这一点，您需要分析您的应用程序，查看有多少“长时间运行”的请求导致后续请求排队，而不是由 IIS 处理。决定归结为处于这样一种情况，即付出代价高昂的上下文切换代价低于您将获得的回报。如果您的瓶颈是某个页面或服务导致传入请求被推迟，那么开始考虑异步工作可能是一个好主意。但是，您也可能在请求中做了太多工作，这可能是您需要重构代码的“代码异味”。

最后，这取决于。

这是MSDN 的摘录。

通常，当满足以下条件时，使用异步管道：

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

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

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

  • 您希望提供一种机制，让用户取消长时间运行的请求。

虽然链接是关于 MVC 的，但这个想法也适用于其他风格的 ASP.NET。

于 2013-01-18T03:12:10.703 回答