Node.js, c10k y Redis
Alberto Gimeno Brieba
Este mail está sólo ligeramente relacionado con Java. Pero creo que
será de interés para más de uno.
Recientemente he comenzado un proyecto personal, que posiblemente se
convertirá en un proyecto empresarial. Estoy desarrollando un
webservice que en caso de que tenga cierto éxito tendrá que soportar
niveles muy elevados de peticiones por segundo.
Es por eso que como base de datos he evaluado bases de datos NoSQL,
especialmente bases de datos clave-valor: memachedb y redis. Al final
me he quedado con Redis porque soporta algunas cosas interesantes,
como son los tipos de datos lista, sets, y sets ordenados. Y por
soportar "about 110000 SETs per second, about 81000 GETs per second."
Redis
http://code.google.com/p/redis/
Tipos de datos
http://code.google.com/p/redis/wiki/IntroductionToRedisDataTypes
Benchmarks
http://code.google.com/p/redis/wiki/Benchmarks
A nivel de lenguaje de programación y servidor http estaba evaluando
apache mina y jboss netty. Pero al final me he decantado por node.js,
que está en un momento de ebullición y tiene un cliente para redis de
muy buena calidad:
https://github.com/mranney/node_redis
Al escalar a más de 10.000 conexiones abiertas a la vez en el servidor
http, el cuello de botella se encuentra en la arquitectura del
servidor http. El problema es que normalmente se programan creando un
thread por cada conexión. Y esto se convierte en un problema a esos
niveles de carga, porque los threads suelen quedar bloqueados
esperando un resultado de la base de datos, o esperando cargar un
fichero en memoria, etc. Así existen de repente miles de threads
bloqueados y el scheduler del sistema operativo pierde la mayor parte
del tiempo de CPU (hasta 95% en algunos benchmarks) cambiando de un
thread a otro, pero la mayoría de ellos parados por alguna llamada
bloqueante. Además de que el consumo de memoria también se incrementa
considerablemente.
La solución es programar el servidor http y la aplicación usando
siempre llamadas no bloqueantes. Todo (práctiamente todo) se ejecuta
en un único proceso: el del servidor http, y se usan llamadas
asíncronas a través de callbacks / eventos.
Por ejemplo la manera "bloqueante" de acceder a una base de datos:
var resultado = consultaDB(...);
// hacer algo con el resultado
La manera asíncrona / no bloqueante
consultaDB(..., function(resultado) {
// hacer algo con el resultado
});
En node.js están obsesionados con esto, y eso me gusta. Se trata de
una librería javascript para crear aplicaciones de red no bloqueantes.
Internamente está desarrollada en C, y no contiene ningún tipo de
llamada bloqueante. Es decir, es "imposible" que cometas un error
haciendo una llamada bloqueante, porque prácticamente no hay forma de
hacerlo. Hay alguna excepción, pero aislada y razonable.
En Java la manera de programar un servidor no bloqueante sería a
través de Java NIO (non-blocking input-output). Existen librerías de
alto nivel que soportan HTTP y otros protocolos. Por ejemplo Apache
Mina o JBoss Netty. En algunos benchmarks he visto que soportan unas
20 - 25.000 conexiones por segundo.
Como curiosidad en mi "investigación" he encontrado un artículo
interesante de una empresa que necesita tener conexiones abiertas
permanentemente desde sus servidores a aplicaciones Android. Puede que
las conexiones estén inactivas, pero necesitan están abiertas para un
óptimo rendimiento. Han conseguido 500.000 conexiones concurrentes con
una solución propia hecha con Java NIO.
http://blog.urbanairship.com/blog/2010/08/24/c500k-in-action-at-urban-airship/
En su primer intento el software soportaba 15 veces menos conexiones.
Así que en vez de un servidor hubieran necesitado 15. Eso les habrá
ahorrado mucho dinero.
Como veis me interesa mucho este tema. Y creo que de aquí en adelante
va a ser cada vez más necesario construir sistemas de esta manera.
Porque por ejemplo en móviles están surgiendo muchos juegos en red.
Imaginad tener que soportar 500k usuarios conectados a la vez a un
juego.
Una aplicación que quiero hacer también es un chat en el móvil
(iPhone) conectado permanentemente a un servidor web hecho con nodejs,
y por detrás una base de datos redis utilizando pub/sub:
http://code.google.com/p/redis/wiki/PublishSubscribe
Bueno, lo dejo ya, que en vez de un mail parece un artículo xD Comento
esto en la lista por si a alguien le interesa el tema, para
intercambiar experiencias y opiniones.
¡Un saludo!
---
Alberto Gimeno Brieba
http://www.google.com/profiles/gimenete
gnz/vnk
Hola,
Este mail está sólo ligeramente relacionado con Java. Pero creo que
será de interés para más de uno.
Muy interesante!
Alberto Gimeno Brieba
http://bulk.fefe.de/scalable-networking.pdf
Llegué a ella a través de la sección About (interesante leerla
también) de nodejs.org
---
Alberto Gimeno Brieba
http://www.google.com/profiles/gimenete
2010/12/20 gnz/vnk <gnz.g...@gmail.com>:
> --
> Has recibido este mensaje porque estás suscrito al grupo "zaragozajug" de
> Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a
> zarag...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a
> zaragozajug...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en
> http://groups.google.com/group/zaragozajug?hl=es.
>
hector
Interesante tu post/articulo. He descubierto nuevas herramientas. A ver si le echo un ojo al pdf (aunque si que es largo, si).
On lunes 20 de diciembre de 2010 at 19:58, Alberto Gimeno Brieba wrote:
Especialmente interesante esta presentación, aunque un poco larga:
http://bulk.fefe.de/scalable-networking.pdf
Llegué a ella a través de la sección About (interesante leerla
también) de nodejs.org
---
Alberto Gimeno Brieba
http://www.google.com/profiles/gimenete
2010/12/20 gnz/vnk <gnz.g...@gmail.com>:
2010/12/20 Alberto Gimeno Brieba
>
> Hola,
>
> Este mail está sólo ligeramente relacionado con Java. Pero creo que
> será de interés para más de uno.
Muy interesante!
--
Has recibido este mensaje porque estás suscrito al grupo "zaragozajug" de
Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a
zarag...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a
zaragozajug...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en
http://groups.google.com/group/zaragozajug?hl=es.
Alberto Gimeno Brieba
Enviado desde mi iPhone