我正在尝试将长轮询（“反向 ajax”、“http 推送”）功能改进到在 .NET 3.5 SP1 上运行的现有 ASP.NET MVC 1 Web 应用程序。由于此应用程序有数千个并发用户，并且所有用户都将使用长轮询功能，我担心我会遇到难以预见和测试的服务器和连接限制。
阅读Thomas Marquardt 关于 IIS 7.0 和 6.0 上的 ASP.NET 线程使用的文章，在此处和其他地方的许多有关长轮询的问题中都引用了该文章，似乎 >运行 ASP.NET MVC 1 应用程序（在 .NET 中）的 Windows Server 2008 R2（带有 IIS 7.5）的默认设置3.5 SP1），其中使用 MVC Futures 的异步控制器实现长轮询功能将无法能够为数千个用户提供服务。
第一个罪魁祸首似乎是 maxConcurrentRequestsPerCPU ，根据 Marquardt 的说法，在 .NET 3.5 SP1 中设置为 12。这意味着数千个并发长轮询将需要数百个 CPU，对吧？由于无论是否使用异步控制器，长轮询仍然是 HTTP 请求。我需要增加这个。 我的理解正确吗？
由于我使用的是异步控制器，我假设我不需要更改每个 CPU 的并发工作线程数，因为等待长轮询的线程扳机将松开。 我的理解正确吗？或者这是否与长轮询操作方法中“等待”的具体完成方式不同？ （我计划使用事件。）
除此之外，我还会遇到其他限制吗？我不想开始随机增加 machine.config 或 aspnet.config （甚至 web.config）中的值，并且我'如果可能的话，我想保留processModel的autoConfig。
（我已经阅读了这里的所有问题，但没有人专门深入研究有关此问题的细节，大概是因为它随 CPU 数量、CLR 版本等而变化。）
提前致谢！
I'm trying to retro-fit a long poll ("reverse ajax", "http push") feature into an existing ASP.NET MVC 1 web application running on .NET 3.5 SP1. Since this applications has thousands of concurrent users, and all of them will use the long poll feature, I'm worried that I will run into server and connection limits which are hard to fore-see and test.
Having read Thomas Marquardt's article on ASP.NET Thread Usage on IIS 7.0 and 6.0, which is referenced in many questions about long polling here and elsewhere, it seems that the default settings for a Windows Server 2008 R2 (with IIS 7.5) running an ASP.NET MVC 1 application (in .NET 3.5 SP1) where the long poll feature is implemented using asynchronous controllers from MVC Futures will not be able to serve thousands of users.
The first culprit seems to be maxConcurrentRequestsPerCPU, which in .NET 3.5 SP1 is set to 12 according to Marquardt. This means thousands of concurrent long polls would require hundreds of CPUs, right? Since whether or not using asynchronous controllers, a long poll is still an HTTP request. I'd need to increase this. Is my understanding here correct?
Since I'm using asynchronous controllers, I'm assuming I won't need to alter the number of concurrent worker threads per CPU, since the thread waiting for the long poll to trigger will be unwound. Is my understanding here correct? Or does this vary with how exactly the "waiting" in the long poll action method is accomplished? (I was planning on using events.)
In addition to this, are there other limitations I will run into? I don't want to start randomly increasing values in machine.config or aspnet.config (or even web.config), and I'd like to keep the autoConfig of the processModel, if possible.
(I've read all the questions here, but none specifically dig into details regarding this, presumably since it varies with number of CPUs, CLR version, etc.)
Thanks in advance!
发布评论
评论（1）
我认为您误解了异步控制器的要点。异步控制器用于长时间运行的网络调用（注意：不是长轮询调用）。这意味着如果一个操作需要时间来处理/返回，它将被异步处理，立即将控制权返回给客户端。
如果要实现长轮询，请使用 SignalR
http://www.hanselman.com/blog/AsynchronousScalableWebApplicationsWithRealtimePersistentLongrunningConnectionsWithSignalR .aspx
I think you're misunderstanding the point of Asynchronous Controllers. Async controllers are used for long-running web calls (note: not long polling calls). Meaning that if an action takes time to process/return, it will be processed asynchronously, returning control to the client immediately.
If you want to implement long polling, use SignalR
http://www.hanselman.com/blog/AsynchronousScalableWebApplicationsWithRealtimePersistentLongrunningConnectionsWithSignalR.aspx