我正在尝试将长轮询(“反向 ajax”、“http 推送”)功能 retrofit 到在 .NET 3.5 SP1 上运行的现有 ASP.NET MVC 1 Web 应用程序 .由于此应用程序有数千个并发用户，并且所有用户都将使用长轮询功能，我担心我会遇到难以预见和测试的服务器和连接限制。
已阅读 Thomas Marquardt's article on ASP.NET Thread Usage on IIS 7.0 and 6.0 ，这里和其他地方的许多关于长轮询的问题都引用了它，似乎 默认 运行 ASP.NET MVC 1 应用程序(在 .NET 3.5 SP1 中)的 Windows Server 2008 R2(带有 IIS 7.5)的设置，其中使用 MVC Futures 的异步 Controller 实现长轮询功能将 不是 能够为数以千计的用户提供服务。
第一个罪魁祸首似乎是maxConcurrentRequestsPerCPU ，在 .NET 3.5 SP1 中设置为 12 根据马夸特的说法。这意味着数千个并发的长轮询需要数百个 CPU，对吗？由于是否使用异步 Controller ，长时间轮询仍然是一个 HTTP 请求。我需要增加这个。 我这里的理解正确吗？
由于我使用的是异步 Controller ，因此我假设我不需要更改每个 CPU 的并发工作线程数，因为等待长轮询触发的线程将被解除。 我这里的理解正确吗？ 或者这是否随着长轮询操作方法中“等待”的完成方式而有所不同？ (我打算使用事件。)
除此之外，我还会遇到其他限制吗？我不想开始随机增加 machine.config 中的值或 aspnet.config (甚至 web.config )，我想保留 autoConfig的processModel ， 如果可能的话。
(我已经阅读了这里的所有问题，但没有人专门深入研究这方面的细节，大概是因为它随 CPU 数量、CLR 版本等而变化。)
提前致谢!
最佳答案
我认为您误解了异步 Controller 的意义。异步 Controller 用于长时间运行的网络调用(注意: 不是 长轮询调用)。这意味着如果一个 Action 需要时间来处理/返回，它将被异步处理，立即将控制权返回给客户端。
如果要实现长轮询，请使用 SignalR
http://www.hanselman.com/blog/AsynchronousScalableWebApplicationsWithRealtimePersistentLongrunningConnectionsWithSignalR.aspx
关于asp.net-mvc - 使用 MVC Futures 的异步 Controller 在 .NET 3.5 SP1 中的 ASP.NET MVC 1 中长轮询的服务器和连接限制，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6897978/