Barrapunto

Del artículo (del de javahispano, no del original)

A pesar del paso del tiempo, que ha conllevado una drástica mejora en la gestión de hilos que introdujo el kernel 2.6 (Linux NTPL), la disminución del "coste" de la sincronización de hilos en las máquinas virtuales modernas y la normalización de los sistemas multi-núcleo (lo que hace nada práctico el modelo SEDA puro de un sólo hilo), la idea de que la técnica NIO es superior en rendimiento y escalabilidad a IO, ha seguido prevaleciendo aunque sin datos modernos que lo justificaran.

¿Y que tal un modelo mixto basado en threads y eventos [apache.org]? Yo diría que es el mejor de los mundos...

Supongo además que con los nuevos procesadores multinúcleo el usar procesos o threads cada vez estará menos penalizado, además de las distintas cpus vendrán cada ven más optimizadas para guardar y cargar rápidamente el contexto de una aplicación.

Puede que de hecho la técnica de la E/S no bloqueante acabe estando desaconsejada por razones de rendimiento.

Hace más de 20 años, antes del pentium, ya existían ordenadores de varias CPUS, que no es lo mismo que dos núcleos, pero es parecido. Y ya de aquella separar los programas en procesos o en hilos era lo mejor. Oye, pero si quieres hacer una tésis sobre el tema adelante.

Viendo este post [theserverside.com] hablan de que la maquina virtual de Java no tiene soporte para epoll, solo poll. No sé como será este soporte ahora ni de cuando es el estudio del que hablan en la noticia. Según este benchmark de libevent [daemonforums.org] la diferencia si que puede tener importancia en los resultados.

Una aplicación bloqueante es mucho más fácil de programar, si se te detiene un hilo no se para toda la aplicación (como si pasa en una aplicación por eventos). Una aplicación bloqueante que haga cosas y no afecte al rendimiento tiene su cosa, con los bloqueos te estas cargando la concurrencia.

Resumiendo: falta el enlace al artículo original para ver que librería de eventos se está usando. Faltan pruebas con una aplicación real programada de una y de otra forma (que tipo de aplicación va a ser creo que es fundamental para elegir la arquitectura apropiada).

Si solo mides la velocidad, quizas si (Bueno, seguro que si que es mas rapida la sincrona). Pero no es eso de lo que va NIO. NIO va de ESCALABILIDAD, no de velocidad.
Si tienes 10000 conexiones en blocking, obviamente necesitas 10000 threads.
Estos solo se puede hacer bien con NIO, una buena libreria de eventos con un pool fijo de threads atendiendolos.
Tambien podrias usar la tactica del Big Loop, como punto medio, pero solo sirve para transacciones simples y a la larga escala peor que NIO.

Para los que no saben que onda con esto:

Los sockets son conexiones de redes a cualquier computadora usando el protocolo TCP.

La concurrencia desde el punto de vista de estas aplicaciones, es el soportar el mayor numero posible de clientes simultaneos.

El througput se puede entender como el flujo de bytes por unidad de tiempo.

Uno de los grandes problemas al diseñar software de servidores de redes es el mantener la mayor concurrencia sin que esto afecte de manera negativa en el througput.

La idea es dar soporte a tantos clientes como se pueda, sin afectar el througput del servidor.

Esta es una tarea compleja y dificil, y siempre los investigadores estan en busca de varios algoritmos para poder hacer esto. Para ello se basan la mayoria en sockets no bloqueantes.

La I/O de sockets bloqueante espera hasta que:
*Haya una conexion disponible
*Existan datos en el socket listos para lectura
*El socket este listo para escribir.

Los sockets no bloqueantes no ponen a dormir el proceso hasta que ocurra algun evento de estos y en su lugar continua la ejecucion del programa.

Y que es eso de poll y epoll?

Simple: Se requiere de una llamada al sistema que nos avise cuando hay actividad en un socket (incluyendo alguna conexion nueva de un cliente).

La usada de forma tradicional en los unix es select(), pero es algo lenta y vieja (aunque portable). La llamada poll() es muy especifica de linux, (aunque tambien se usa en cygwin, creo que de hecho ya esta en POSIX), que aporta una mayor velocidad. Pero epoll() es mucho mas rapida. Cada unix integra su propia alternativa a select(), siendo epoll() la propuesta de Linux, kqueue la propuesta de los B y ports la de Solaris.

Existe una nueva llamada AIO pero esta en vias de estandarizarse por POSIX ( o no se si ya?)

Bueno, la idea es obtener conexiones de clientes mas rapido con estas interfaces. La idea es tambien capturar la mayor cantidad de clientes posibles y darles la atencion tan rapido como se pueda, eliminando cualquier tiempo muerto de procesador y tratando que el cuello de botella este en el HW.

Una vez que ya adquirimos la conexion, decidimos que hacer con ella dependiendo del algoritmo a usar y de la naturaleza de la aplicacion.

Algunos algoritmos se basan en un pool de procesos, que crean un nuevo proceso para cada conexion recibida(apache 1.x)

Otros crean un pool de procesos y dentro de cada uno, un pool de threads de usuario para atender a cada uno. (Apache 2.x, Meta1)

Hay quien ha diseñado librerias para ello (StateThreads)

Cada una tiene sus ventajas e inconvenientes. SEDA es un algoritmo de Pipeline que "embona" las diversas fases del protocolo en threads: un thread para cada fase.

Sin embargo, me parece mas interesante la tecnica de Cherokee Web Server, que crea un grupo de kernel threads y para cada uno crea varias conexiones poniendolas en un pipeline para cada fase del protocolo. Esto aprovecha mucho mejor los procesadores en equipos multicore, ademas de que al usar algoritmos de caches mas eficientes y mmap() para lecturas y escrituras al disco deja el cuello de botella en la conexion y el hardware. Pero lo mas importante es que se pueden tener cientos de clientes conectados y seguir recibiendo aun mas conexiones, evitando ademas que el througput se degrade por ello ;)

En fin, hay muchas formas y algoritmos de lograr las cosas. Y SEDA es un algoritmo mas, que esta aun por comprobar si en realidad llega a alcanzar el santo grial de las aplicaciones de servidores de redes, ya que hasta donde se, la unica implementacion que existe esta hecha en Java, que nada tiene que hacer contra una implementacion en C.

Espero que alguien haya entendido todo este rollo. Tambien me hice bolas al principio, pero ya que mi tema de tesis de maestria esta relacionado, pense que podria aportar algo...

¡Eh! ¡Tú! ¡No te metas con OpenSuse!

¿Me podrías decir cómo consigue Microsoft meter su basura en todos los PC que se venden?

Te recomiendo que te leas Why I hate Microsoft [vanwensveen.nl], en donde se explican muy bien (aunque en inglés) las barbaridades (y méritos, también hay que decirlo) que Microsoft ha hecho durante su vida.

Te sorprenderás de lo que es capaz de hacer...

DON'T FEED THE TROLL [zerror.com]