ASP.NET MVC 的 AsyncController 可以用于服务大量并发挂起请求（长轮询）吗？
Node.js、Tornado 和 Twisted 等框架让开发人员可以创建支持大量并发挂起请求 (10k+) 的服务器推送应用程序。据我了解，他们都是通过不创建线程来服务每个挂起的请求来实现这一点的。
AsyncController 可以用于服务大量不活动的并发请求吗？
如果是这样，是否有任何相当大的 ASP.NET MVC 网站使用这种方法来创建长轮询应用程序？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
AsyncController 在以下情况下很有用（与普通控制器相比）：
您有一个长时间运行的任务，并且该任务通常由其他层（Web 服务、数据库等）通过使用 I/O 完成端口。因此，请求在工作线程上启动，然后调用 BeginXXX 方法，该方法将打开一个 IOCP（如果支持，则没有用，因为它只会绘制另一个工作线程），工作线程将立即返回到线程池。在执行长操作期间，服务器上不会消耗任何工作线程。一旦完成，它就会向 IOCP 发出信号，异步控制器从池中提取另一个线程来简单地终止请求并将结果返回到视图。这里有一些事情需要注意：您使用异步控制器而不是普通控制器的事实对客户端来说绝对没有区别：他仍然需要等待相同的时间来完成请求，不要错误地认为异步控制器会让您的缓慢操作运行得更快。简而言之，工作线程将被垄断的时间更少，因此可能使其他请求运行得更快。
总结一下：对于快速运行的请求，与普通控制器相比，异步控制器不会给您带来任何好处。对于缓慢的请求，它们可以，但这取决于长时间运行的操作的性质以及它是否受 CPU 或 I/O 限制。对于 CPU 密集型任务，异步控制器也不是更有用。但在所有情况下，您都应该对应用程序执行广泛的负载测试。
这是MSDN 上的一篇非常好的文章，它解释了 ASP.NET 中的异步请求。
这是一篇博客文章 说明了如何使用异步控制器来实现长轮询。
AsyncController is useful (compared to a normal controller) in the following situation:
You have a long running task and this task is normally achieved by some other tier (web service, database, ...) by using I/O Completion Ports. So the request starts on a worker thread, then you call the BeginXXX method which will open an IOCP (if it supports it, if not it is useless as it will simply draw another worker thread) and the worker thread will be immediately returned to the thread pool. During the execution of the long operation no worker threads are being consumed on the server. Once it completes it signals the IOCP, the async controller draws another thread from the pool to simply terminate the request and return the results to the view. There are a few things to note here: the fact that you used an async controller instead of a normal controller makes absolutely no difference to the client: he will still need to wait the same amount of time for the request to finish, don't get the false impression that an async controller will make your slow operation run faster. Simply the worker threads will be monopolized for less time and so potentially making other requests run faster.
To sum up: for fast running requests async controllers won't bring you any benefit compared to normal controllers. For slow requests they could but it will depend on the nature of the long running operation and whether it is CPU or I/O bound. For CPU bound tasks async controllers are not more useful either. But in all cases you should perform extensive load testing on your application.
Here's a very good article on MSDN which explains async requests in ASP.NET.
And here's a blog post which illustrates how an async controller could be used to implement long-polling.
我最近写了一个长轮询聊天服务器的简单示例 使用基于 Clay Lenhart 的精彩文章，但我还没有机会通过大量连接来真正测试它。
您可以使用我根据 BitBucket 项目的源代码设置的AppHarbor 部署示例。
另外，更多信息可以从我的解释该项目的博客文章。
I recently wrote a simple example of a Long Polling Chat Server using MVC 3 Async Controllers based on a great article by Clay Lenhart but I haven't had the chance to really test it out with a bunch of connections.
You can use the example on a AppHarbor deployment I set up based on the source from the BitBucket project.
Also, more information available from my blog post explaining the project.