2010-11-10 9 views
6

Estoy creando un servidor para supervisar la presencia en línea de clientes en una página web.Cómo gestionar conexiones HTTP de hasta 100k en .Net

  • Habrá 80-100 000 (ochenta mil) clientes simultáneos para monitorear.
  • Estoy usando .Net para escribir esto.

Los clientes se pondrán en contacto con un servidor (separado) mediante JavaScript (en la página HTML) para informar al servidor que están activos/en línea.

estoy pensando en uno de los dos enfoques:

  1. Las conexiones persistentes con mantenimiento de conexión envía regularmente. Esto me dará mucha más precisión sobre cuándo los clientes se desconectan y no necesito actualizar la estructura de la memoria (onlineinfo) con demasiada frecuencia porque sabemos cuándo el cliente entra y sale. Beneficios adicionales para el equipo de red/ancho de banda.

  2. Los clientes (re) se conectan a intervalos para indicar al servidor que están activos. Esto requiere muchas conexiones y necesariamente disminuirá la precisión. Imagino que intervalos de 2-3 minutos es lo mejor que podemos hacer. 80k/120 = 660 conexiones por segundo ... ASP.Net no se ejecuta demasiado rápido, así que no estoy seguro de esto. Sistema de 8 núcleos = ~ 10 ms por ejecución.

Con estas muchas conexiones, obviamente, hay algunas limitaciones. No puedo generar tantos subprocesos simultáneamente, por ejemplo. 1 solicitud para que IIS genere una aplicación ASP.Net usará 1 hilo hasta que se complete la solicitud.

¿Es la mejor opción para escribir un servidor http autónomo? No .Nets TcpListener aprovecha httpd.sys (IIS)?

Cualquier idea (constructiva) sobre el tema sería apreciada.

Editar: Adición de enlaces útiles a este post encontrado siguiendo los enlaces de Nicolas Repiquets respuesta:

+7

Justa pensó: ¿Ha considerado una estrategia de equilibrio de carga para esto con varios servidores? – byte

+0

Siempre y cuando los clientes no requieran mucho procesamiento para cada "solicitud" mantenida viva, no veo ninguna razón por la que no pueda hacer esto. – Gabe

+0

¡Problema interesante! Lo único que puedo aconsejarle es que juegue con límites .NET y TCP/IP. Cualquiera que sea la solución que implemente, piense primero cómo escalar. (divida la carga en varios servidores) –

Respuesta

4

100 000 conexiones persistentes es no es una opción viable.

Enviar solicitudes HTTP en el intervalo es mucho más factible, y escribir un servidor HTTP dedicado es una opción interesante IMO.

Eche un vistazo a this question para algunas orientaciones.

+0

¿Por qué no es una opción viable? Windows admite esta cantidad de conexiones siempre que no sea/desde los mismos pares de IP, en cuyo caso se aplica el límite de 65k. –

+1

Te quedarás sin memoria mucho antes de que te quedes sin puerto libre. Intente _gestimate_ la huella de memoria de una sola conexión y multiplique por 100000 ... –

+1

Nicolas: suponiendo que cada conexión requiere 1k de datos y tiene 100.000 conexiones, el uso total será 100.000k o 100M. Ha pasado más de una década desde que tenía un servidor que no tenía 100M de memoria. – Gabe

0

Sé que específicamente dices .NET, pero probablemente deberías echar un vistazo a NodeJS, ya que hace exactamente lo que estás tratando de hacer, pero es el lado del servidor JavaScript.

Cuestiones relacionadas