Todos hemos leído los puntos de referencia y conocemos los hechos: los servidores de red asincrónicos basados en eventos son más rápidos que sus contraseñas enhebradas. Piense lighttpd o Zeus contra Apache o IIS. ¿Porqué es eso?¿Por qué las aplicaciones de red basadas en eventos son inherentemente más rápidas que las enrutadas?
Creo que la base de los sucesos no es la cuestión: es una solución de agrupación de subprocesos de E/S multiplataforma, no bloqueable, sockets seleccionables.
En el primer caso, usted está manejando todas las entradas que entran independientemente de lo que se está utilizando, por lo que no hay bloqueo en las lecturas, un solo "oyente". El subproceso único de escucha transfiere datos a lo que pueden ser subprocesos de trabajo de diferentes tipos, en lugar de uno para cada conexión. Una vez más, no hay bloqueo al escribir ninguno de los datos, por lo que el manejador de datos solo puede ejecutarlo por separado. Debido a que esta solución es en su mayoría IO de lectura/escritura, no ocupa mucho tiempo de CPU, por lo que su aplicación puede tomar eso para hacer lo que quiera.
En una solución de grupo de subprocesos, usted tiene subprocesos individuales que manejan cada conexión, por lo que tienen que compartir el tiempo para el cambio de contexto dentro y fuera de cada 'escucha'. En esta solución, las operaciones CPU + IO están en el mismo subproceso, que obtiene un intervalo de tiempo, por lo que terminas esperando en operaciones IO para completar por subproceso (bloqueo) que tradicionalmente se podía hacer sin utilizar el tiempo de CPU.
Google para IO no bloqueante para obtener más detalles, y también puede encontrar algunas comparaciones frente a grupos de subprocesos.
(si alguien puede aclarar estos puntos, se sienten libres)
No se trata de los hilos de verdad. Se trata de la forma en que los hilos se utilizan para atender las solicitudes. Para algo como lighttpd tienes un único hilo que da servicio a múltiples conexiones a través de eventos. Para las versiones anteriores de apache, usted tenía un proceso por conexión y el proceso despertaba con los datos entrantes, por lo que terminaba con un número muy grande cuando había muchas solicitudes. Ahora, sin embargo, con MPM apache también se basa en eventos, vea apache MPM event.
Realmente depende de lo que esté haciendo; la programación basada en eventos es ciertamente complicada para aplicaciones no triviales. Ser un servidor web es realmente un problema muy trivial bien entendido y tanto los modelos basados en eventos como los enrutados funcionan bastante bien en sistemas operativos modernos.
El desarrollo correcto de aplicaciones de servidor más complejas en un modelo de eventos suele ser bastante complicado: las aplicaciones con subprocesos son mucho más fáciles de escribir. Este puede ser el factor decisivo en lugar del rendimiento.
Las aplicaciones controladas por eventos son no intrínsecamente más rápidas.
De Why Events Are a Bad Idea (for High-Concurrency Servers):
We examine the claimed strengths of events over threads and show that the
weaknesses of threads are artifacts of specific threading implementations
and not inherent to the threading paradigm. As evidence, we present a
user-level thread package that scales to 100,000 threads and achieves
excellent performance in a web server.
Esto fue en 2003. Sin duda, el estado de enhebrar el sistema operativo moderno ha mejorado desde entonces. Escribir el núcleo de un servidor basado en eventos significa reinventar la multitarea cooperativa (estilo Windows 3.1) en su código, muy probablemente en un sistema operativo que ya admite multitarea preventiva adecuada y sin la ventaja de una conmutación de contexto transparente . Esto significa que debe administrar el estado en el montón que normalmente estaría implícito en el puntero de instrucción o almacenado en una variable de pila. (Si su lenguaje los tiene, los cierres alivian este dolor significativamente. Intentar hacer esto en C es mucho menos divertido.)
Esto también significa que usted gana todas las advertencias que la multitarea cooperativa implica.Si uno de sus controladores de eventos tarda un tiempo en ejecutarse por cualquier motivo, lo detiene. Las solicitudes totalmente no relacionadas demoran. Incluso las operaciones de CPU-invensive largas deben enviarse a otro lugar para evitar esto. Cuando habla del núcleo de un servidor de alta concurrencia, 'operación larga' es un término relativo, del orden de microsegundos para un servidor que se espera maneje 100.000 solicitudes por segundo. Espero que el sistema de memoria virtual nunca tenga que sacar páginas del disco por ti.
Obtener un buen rendimiento de una arquitectura basada en eventos puede ser complicado, especialmente cuando se considera la latencia y no solo el rendimiento. (Por supuesto, hay un montón de errores que puede hacer con hilos, así concurrencia es todavía difícil..)
Un par de preguntas importantes para el autor de una nueva aplicación de servidor:
Gracias por la respuesta. – dowski