asp.net - 是否有任何理由“不”在每个应用程序中实现异步 ASP.NET 网页？

Question

关于异步ASP.NET网页article on MSDN .

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

第二个问题:是否有任何现实世界的研究/示例来说明在不同的网络应用程序情况下优势开始显现？或者只是吸一下看看？

Answer 1

来自您自己的链接:

Only I/O-bound operations are good candidates for becoming async action methods on an asynchronous controller class. An I/O-bound operation is an operation that doesn’t depend on the local CPU for completion. When an I/O-bound operation is active, the CPU just waits for data to be processed (that is, downloaded) from external storage (a database or a remote service). I/O-bound operations are in contrast to CPU-bound operations, where the completion of a task depends on the activity of the CPU.

异步页面不是免费的，它们确实是有代价的。当您的页面对服务进行外部调用或执行某些长时间运行的非 CPU 绑定(bind)操作时，它们通常很有用。否则，您可能会破坏 CPU，从而导致比异步之前更糟糕的情况。

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

Here is another link包含何时/何时不使用异步页面的信息。

编辑

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

最后，这取决于。

这里是an exerpt from MSDN .

In general, use asynchronous pipelines when the following conditions are true:

• The operations are network-bound or I/O-bound instead of CPU-bound.

• Testing shows that the blocking operations are a bottleneck in site performance and that IIS can service more requests by using asynchronous action methods for these blocking calls.

• Parallelism is more important than simplicity of code.

• You want to provide a mechanism that lets users cancel a long-running request.

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