He publicado un nuevo artículo en CometDaily.com. El artículo inicialmente revisa la técnica usada en ItsNat para proporcionar Comet en la forma long-polling. Dicha técnica está basada en el estándar servlet un hilo por petición. A lo largo del artículo se revisa la falsa creencia de que los sistemas basados en múltiples hilos (IO) son lentos y no escalables respecto a las técnicas modernas de muy pocos hilos basándose en NIO.
En los últimos años se ha estado apostado por la técnica de comunicaciones asíncronas (no bloqueantes), por ejemplo en servidores de aplicaciones, en contra de la técnica basada en hilos o síncrona (hilo por conexión, en donde los hilos se bloquean cuando no pueden leer o escribir).
Como justificación se partía de la idea de que la técnica de comunicación asíncrona es superior tanto en rendimiento y en escalabilidad a la técnica clásica síncrona. Dicha idea se basó inicialmente en el proyecto SEDA basado a su vez en la tesis doctoral de Matt Welsh en torno a 2001. En el ámbito Java se ha concretado en el predominio del uso de NIO en vez de IO (el proyecto SEDA está también basado en Java).
El artículo plantea que la tesis de Welsh era válida en aquella época sobre todo en sistemas Linux basados en el kernel 2.4 o anteriores y máquinas virtuales Java antiguas.
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.
El artículo cuestiona esta creencia a partir de las investigaciones de Paul Tyma, ingeniero software en Google, en donde a través de varios tests da la vuelta a las asunciones típicas de este terreno tal y como que NIO tiene mayor rendimiento que IO para una sola conexión o que en la gestión de muchas conexiones concurrentes la solución IO o basada en muchos hilos (hilo por conexión) no es escalable porque la gestión de muchos hilos tiene un alto coste de tiempo (cuantas más conexiones, más hilos, más degradación). Paul concluye por tanto que IO no sólo es más rápido que NIO en una sola conexión, además la escalabilidad no se ve prácticamente en nada afectada por el aumento de hilos (los tests de Tyma abarcan hasta 1000 conexiones-hilos).
El estudio de Paul Tyma finalmente plantea que a fin de cuentas la gestión de conexiones y gestión de datos (estado o contexto) de dichas conexiones en NIO es básicamente lo mismo que ocurre en el kernel del sistema operativo en la gestión de hilos, pues en realidad los procesadores (más exactamente cores) son en general monohilo, y por tanto la conmutación de hilos es básicamente un problema de software similar al de la conmutación entre conexiones, en ambos casos para hacernos creer que existe un verdadero paralelismo.
Finalmente el artículo concluye que el estudio de Paul Tyma al haberse realizado en el nivel de conexión (sockets), no puede extrapolarse directamente a un nivel de servlet al existir más capas y un protocolo concreto (HTTP). Lo que ciertamente determinan los tests de Tyma es que ya no puede afirmarse con rotundidad la superioridad incuestionable de NIO frente a IO, diferentes escenarios pueden dar ligeras ventajas a uno u otro pero difícilmente una técnica será ampliamente superior
en rendimiento y escalabilidad a la otra pues en cierto modo ambas técnicas son esencialmente similares e IO tiene la ventaja de su mayor facilidad de programación.
domingo, noviembre 30, 2008 at 7:26PM