http - multiprogramación - multitarea

Event Loop vs multiproceso bloqueando IO

Question

Estaba leyendo un comentario sobre la arquitectura del servidor.

http://news.ycombinator.com/item?id=520077

En este comentario, la persona dice 3 cosas:

1. El bucle de eventos, una y otra vez, se ha demostrado que realmente brilla para un gran número de conexiones de baja actividad.
2. En comparación, se ha mostrado un modelo de IO de bloqueo con subprocesos o procesos, una y otra vez, para reducir la latencia en una base por solicitud en comparación con un bucle de eventos.
3. En un sistema ligeramente cargado la diferencia es indistinguible. Bajo carga, la mayoría de los bucles de eventos eligen disminuir la velocidad, la mayoría de los modelos de bloqueo eligen deshacerse de la carga.

¿Alguno de estos es verdad?

Y también otro artículo aquí titulado "Por qué los eventos son una mala idea (para servidores de alta concurrencia)"

http://www.usenix.org/events/hotos03/tech/vonbehren.html

Answer 1

No estoy seguro de lo que quieres decir con "actividad baja", pero creo que el factor principal sería cuánto necesitas hacer para manejar cada solicitud. Suponiendo un bucle de eventos de un solo hilo, ningún otro cliente obtendría sus solicitudes manejadas mientras usted manejaba la solicitud actual. Si necesita hacer un montón de cosas para manejar cada solicitud ("lotes" significa algo que requiere una CPU y / o tiempo significativos), y suponiendo que su máquina realmente puede realizar múltiples tareas de manera eficiente (que tomar tiempo no significa esperar recurso, como una sola máquina CPU o similar), obtendría un mejor rendimiento al realizar múltiples tareas. La multitarea podría ser un modelo de bloqueo de multiproceso, pero también podría ser un bucle de eventos de una sola tarea que recopila solicitudes entrantes, llevándolas a una fábrica de trabajadores de multiproceso que las manejaría (a través de la multitarea) y enviándole una respuesta lo antes posible.

No creo que las conexiones lentas con los clientes importen tanto, ya que creo que el sistema operativo lo manejaría de manera eficiente fuera de su aplicación (suponiendo que no bloquee el bucle de eventos para varios viajes de ida y vuelta con el cliente que inicialmente inició la solicitud) , pero no he probado esto yo mismo.

Answer 2

Normalmente, si se espera que la aplicación maneje millones de conexiones, puede combinar un paradigma de subprocesos múltiples con eventos.

1. Primero, genere como N hilos donde N == número de núcleos / procesadores en su máquina. Cada subproceso tendrá una lista de sockets asíncronos que se supone que debe manejar.
2. Luego, para cada nueva conexión desde el aceptador, "balancee la carga" del nuevo socket al hilo con el menor número de socket.
3. Dentro de cada hilo, use un modelo basado en eventos para todos los sockets, de modo que cada hilo pueda manejar múltiples sockets "simultáneamente".

Con este enfoque,

1. Nunca engendras un millón de hilos. Solo tienes tantos como tu sistema puede manejar.
2. Utiliza eventos basados ​​en multinúcleo en lugar de un solo núcleo.