关于异步ASP.NET网页article on MSDN。
长时间运行的页面或高服务器负载的优势显而易见。因此，如果项目中您认为需求可能在某个地方可能很高，那么当使用率增长时，是否有任何理由不在每个Web应用程序中实现异步ASP.NET作为标准？该方法有任何缺点吗？
次要问题：在不同的网络应用环境中，是否有任何真实的研究/例子显示优势何处开始？或者只是吮吸它并看到它？
答案 0 :(得分：7)
从您自己的链接：
只有I / O绑定操作才能成为异步控制器类上异步操作方法的理想选择。 I / O绑定操作是一种不依赖于本地CPU完成的操作。当I / O绑定操作处于活动状态时，CPU只等待从外部存储（数据库或远程服务）处理（即下载）数据。 I / O绑定操作与CPU绑定操作形成对比，其中任务的完成取决于CPU的活动。
异步页面不是免费的，它们确实需要付出代价。当您的页面对服务进行外部调用或执行一些长时间运行的非CPU绑定操作时，它们通常都很好。否则，您可能会瘫痪CPU，使您在异步之前遇到更糟糕的情况。
当你从应用程序的线程池中吃掉一个执行非CPU密集型工作的线程（等待长时间运行的服务的响应）时，我们的想法是使用异步。这样，您的应用程序可以继续处理请求，并且不会开始排队新请求，从而慢慢消耗应用程序的响应速度。
Here is another link包含何时/何时不使用异步页面的信息。
修改
至于什么被认为是“长跑”，你面对的是“这取决于”的糟糕答案。要解决这个问题，您需要对应用程序进行概要分析，查看有多少“长时间运行”的请求导致后续请求被IIS排队，而不是处理。这个决定归结为处于这样一种情况：付出代价高昂的环境转换费用低于你将要做的回报。如果您的瓶颈是导致传入请求被阻止的某个页面或服务，那么开始考虑异步工作可能是个好主意。但是，您可能也在请求中做了太多工作，这可能是您需要重构代码的“代码味道”。
最后，取决于。
通常，在满足以下条件时使用异步管道：
这些操作是网络绑定的或I / O绑定的，而不是CPU绑定的。
测试表明，阻止操作是站点性能的瓶颈，IIS可以通过对这些阻塞调用使用异步操作方法来为更多请求提供服务。
并行性比简单的代码更重要。
您希望提供一种机制，让用户取消长时间运行的请求。
虽然链接是关于MVC的，但这个想法也适用于其他类型的ASP.NET。