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

关于异步ASP.NET网页

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

第二个问题：在不同的web应用情况下，是否有关于优势开始出现的真实研究/示例？还是仅仅是吮吸它，然后看看？

从您自己的链接：

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

异步页面不是免费的，它们是有代价的。当您的页面对服务进行外部调用或执行一些长时间运行的、不受CPU限制的操作时，它们通常是好的。否则，很可能会对CPU造成冲击，从而使您的情况比异步之前更糟

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

包含何时/何时不使用异步页面的信息

编辑

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

最后要看情况而定

这是

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

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

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

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

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

---

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

谢谢，我不知道上下文切换中有重大的错误。尽管如此，我找不到任何关于“长”io绑定操作的定义。考虑到一个标准页面只需1ms的时间，我们是否可以将超过1ms的延迟作为异步页面的候选者？