Server and connection limits for long poll in ASP.NET MVC 1 in .NET 3.5 SP1 using asynchronous controllers from MVC Futures

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 qu开发者_开发百科estions here, but none specifically dig into details regarding this, presumably since it varies with number of CPUs, CLR version, etc.)

Thanks in advance!

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