Bloqueo de eventos frente a bloqueos múltiples 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 brillar para un elevado número de conexiones de baja actividad.
2. En comparación, un modelo IO de bloqueo con subprocesos o procesos se ha demostrado, una y otra vez, para reducir la latencia en cada solicitud en comparación con un bucle de evento.
3. En un sistema con carga ligera, la diferencia es indistinguible. Bajo carga, la mayoría de los bucles de eventos eligen desacelerar, la mayoría de los modelos de bloqueo optan por deshacerse de la carga.

¿Alguno de estos es cierto?

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

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

Answer 1

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

1. Primero, genere como N subprocesos 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, "carga-balancea" el nuevo socket al hilo con el menor número de socket.
3. Dentro de cada subproceso, utilice el modelo basado en eventos para todos los sockets, de modo que cada subproceso pueda manejar varios sockets "simultáneamente".

Con este enfoque,

1. Nunca generar un millón de hilos. Usted solo tiene tantos como su sistema puede manejar.
2. Utiliza eventos basados ​​en multinúcleo en lugar de un solo núcleo.

Answer 2

No está seguro de lo que entendemos por "baja actividad", pero creo que la mayor factor sería la cantidad que realmente necesita hacer para manejar cada solicitud. Suponiendo un bucle de eventos de subproceso único, ningún otro cliente gestionaría sus solicitudes mientras manejaba la solicitud actual. Si necesita hacer muchas cosas para manejar cada solicitud ("lotes" significa algo que requiere una cantidad significativa de CPU y/o tiempo), y suponiendo que su máquina realmente puede realizar múltiples tareas de manera eficiente (que tomarse el tiempo no significa esperar una recurso, como una sola máquina de CPU o similar), obtendría un mejor rendimiento mediante la multitarea. La multitarea podría ser un modelo de bloqueo multiproceso, pero también podría ser un ciclo de evento de tarea única que recopile las solicitudes entrantes, distribuyéndolas en una fábrica de trabajadores multiproceso que las manejaría a su vez (a través de la multitarea) y enviándole una respuesta lo antes posible.

No creo que las conexiones lentas con los clientes importen mucho, ya que creo que el sistema operativo manejaría eso eficientemente fuera de su aplicación (suponiendo que no bloquee el ciclo de eventos para múltiples viajes de ida y vuelta con el cliente que inicialmente inició la solicitud), pero no lo he probado yo mismo.