El problema es que los servidores web tradicionales usan un enfoque de subprocesos por socket para manejar usuarios concurrentes, lo que no siempre es óptimo para las técnicas de sondeo cometas/largas. (Las versiones más nuevas de IIS tienen una forma de conectar sus propios manejadores de conexión, que obtendré también a continuación.)
Para los servidores web tradicionales, más a menudo el objetivo es obtener una conexión, servir al usuario algo lo más rápido posible, y pasar a la siguiente conexión. Si una conexión persiste por mucho tiempo, es porque probablemente esté haciendo algo de manera intensiva, como una gran descarga o una gran consulta, pero en general usa activamente la CPU para que el modelo con subprocesos funcione bastante bien.
En cometa (larga encuesta), normalmente se está conectando a un servidor web donde simplemente espera que ocurra un evento, y la mayoría de las veces. Esto promueve más conexiones concurrentes. También hay chacnes que muchos de estos usuarios esperan que ocurran los mismos eventos en todos los ámbitos.
Asignar un hilo para que el usuario simplemente centrifugue y espere no es un modelo muy óptimo para este tipo de cosas. Un mejor modelo es un servidor web basado en bucle de eventos que hace todo de manera asincrónica, y donde enviar un evento a múltiples usuarios no implica un cambio de contexto costoso para cada cliente. Esto sobre lo que se basa Node.js (usando libevent como su núcleo), así como Ruby Eventmachine, Twisted Python, Friendfeed's Tornado, Jetty, y el servidor basado en C# Manos.
Es por eso que a menudo es más ventajoso tener un cometa hecho en su propio proceso personalizado como servidor personalizado ya que los servidores web tradicionales como Apache y las versiones anteriores de IIS no funcionan en una cuestión que es eficiente para las necesidades de Comet.
Las aplicaciones estándar de ASP.NET están un poco atornilladas debido a que el grupo de subprocesos en .NET está limitado a 25 subprocesos generales y 25 subprocesos de IO (y las conexiones http toman un subproceso de E/S). En realidad, puede estar limitado a ser un poco menos que eso en realidad porque el grupo de subprocesos se comparte con todas las demás cosas en .NET. Sin embargo, puedes cambiar el grupo de subprocesos con una configuración, pero el rendimiento tiende a decaer exponencialmente a medida que más subprocesos ingresas. En teoría, puedes subir este número si puedes garantizar que no crecerás demasiado, y entonces posiblemente solo use monitores de hilos estándar en .NET para construir su propia cosa de despacho de eventos de cometas.
Sin embargo, las aplicaciones .NET que ejecutan versiones más nuevas de IIS sí tienen un rayo de esperanza. Puede crear un IAsyncHttpHandler personalizado. Hay algunas excelentes guías en línea para que lea sobre cómo funciona esto. Con eso puedes construir tu propio grupo de conexiones y atender a tus clientes de manera más eficiente. No es una solución perfecta y tienes que construir mucha tubería por tu cuenta. WebSync es un producto comercial que envuelve esta interfaz para usted y le ofrece algunas piezas de marco de alto nivel con las que puede trabajar sin embargo.
Creo que el nodo no está disponible en Windows, podría estar equivocado. – Robert