Paul Tyma ha publicado en su weblog el resultado de un micro benchmark donde compara el rendimiento de la API no bloqueante NIO con la más tradicional y bloqueante API IO. La primera, una incorporación de Java 1.4, supuestamente debería proporcionar un incremento en el rendimiento al permitir lecturas y escrituras no bloqueantes; esto permite atender más peticiones con un número menor de threads ya que cada thread puede trabajar sobre múltiples canales (channels) de entrada e ir "saltando" de uno a otro según tenga datos disponible en cada momento.
Con el API IO las lecturas y escrituras son bloqueantes y el thread que realiza la operación de lectura o escritura se bloquea hasta que ésta termina, no pudiendo ser empleado en sus tiempos muertos para atender otras peticiones, lo que obliga a tener un número mayor de threads.
Los resultados que Paul Tyma obtiene son justo los contrarios a los esperados; él ha creado un pequeño servidor que responde a peticiones de un montón de clientes y ha obtenido mejor rendimiento en todos los campos empleando el API IO.
No obstante, sus test tienen un pequeño truco: ha empleado una máquina Linux con kernel 2.6.5 y con soporte para threads NPTL, incorporados en la versión 2.6.4 (creo recordar) del kernel y que presentan un rendimiento muy superior a los threads que tradicionalmente ha empleado Linux.
Aunque yo no creo que de sus resultados pueda concluirse que NIO es más eficiente que IO (además, el sólo ha medido métricas relativas a la red, no accesos al disco) sí es una buena prueba de que a veces las máquinas virtuales no están "al día" con los sistemas operativos: estoy convencido de que la máquina virtual que empleaba asumía que se usarían los threads tradicionales de Linux y no los NPTL; si se construyese una máquina virtual optimizada para estos threads seguramente los resultados de los test serían los esperados.
¿Qué opináis vosotros al respecto?
Este mismo tema se planteó en el podcast de Java Posse del 28 del mes pasado (se puede descargar directamente desde iTunes) y es bastante interesante. En esencia conciden totalmente con lo que comenta Abraham y además, como dicen, serían necesarios más tests en otros SOs (Windows, que es actualmente de los mejores soportados) para hacer afirmaciones tan fuertes.
En cualquier caso es genial que alguien no sólo comente una carencia de la JVM actual en un entorno completo, sino que aporte la documentación y el código para demostrarlo. Es un esfuerzo que creo que es útil para toda la comunidad.
Hombre, mas que un pequeño truco, el usar NPTL es la razón, unica y exclusivamente. El mismo lo dice: "Without NPTL of course it's a different story."
Y mas que un "problema" de la maquina virtual, creo yo, es una cuestion del S.O. Es decir, han mejorado mucho el tema de "context switching" entre threads de forma que ahora es mas eficiente que el sistema de espera de interrupciones de E/S. Si en la siguiente version se ponen y mejoran el sistema de interrupciones, pues a lo mejor vuelvea a la situacion anterior.
Tampoco hay que perder de vista que estos resultados son aplicables en muchos casos únicamente a situaciones extremas. Sacar de ahi reglas generales es bastante peligroso.
S!
Buenas, sólo quería aportar un enlace a la discusión correspondiente en TheServerSide
NIO not faster than IO, according to... TSS itself?
Saludos
yo hace como 2 semanas estuve estudiando sobre NIO y como funcionan y lo que entendi, especificamente en sockets es que de la misma forma como funcionan los sockets no bloqueantes de Berkley (creo que esta mal escrito) funciona los SocketChannels de NIO, y yo lo he podido comprobar en servidor para juegos Masivos de multijugadores, que antienden constantemente miles de jugadores. Sin el uso de threads y IO no bloqueantes seria imposible que estos servidores funcionaran, y al estilo de las conexiones con base de datos, ellos manejan un pool de threads que se encarga de gestionar tooodoos esos jugadores.
En el caso particular de java, el servidor de juegos ProjectDarkStar (www.projectdarkstar.com) funciona utilizando NIO, y hasta el momento obtienen mejores resultados. Otro muy buen ejempo de NIO es el servidor Grissly que esta desarrollado bajo el amparo de glashfish umbrella, asi que no creo que esta gente invierta tanto tiempo en desarrollar estos servers si NIO fuera mas lento, sobre todo en estos casos donde es facil comprobar el rendimiento.. Por ejemplo si con IO con 1000 conexiones (igual a 1000 threads) el server funciona, las mismas 1000 conexiones NIO (pero con unos 20threads) funciona, obviamente es mejor.. menos threads, menos recursos, mas rendimiento.. :D
Escribe tu comentario