El haber cambiado de Ruby a Java ayuda Twitter a sobrevivir las elecciones en Estados Unidos
Probablemente hace bastante tiempo que ninguno de vosotros ve la ballena blanca de Twitter, indicador de que el servicio está caído. Una de las claves para haber conseguido una mayor robustez y escalabilidad en el servicio ha sido el propio movimiento de la infraestructura de Twitter desde Ruby, donde comenzó originalmente, hacia Java. Primero comenzaron a usar Scala, que compila a bytecode y corre sobre una máquina virtual Java, y ahora emplean también el lenguaje Java.
Esta migración de Ruby a Java es todavía un trabajo "en proceso" que comenzó en 2008 con la migración de la cola de mensajería del sistema a Scala. En palabras de un desarrollador de Twitter en aquellos momentos:
There's a lot of things that Ruby is great at, but long running processes, Particularly memory intensive ones, Not so much.
En estos momentos la migración de la versión para clientes móviles de Twitter ya es completa, de tal modo que cuando accedeis al servicio desde vuestro terminal móvil las peticiones no tocan ningún código Ruby; es todo código ejecutándose en una máquina virtual Java el que genera la respuesta.
Esta migración es la clave para conseguir haberse desecho de la ballena blanca, tan habitual en los primeros años de Twitter. Y es la clave para ver incrementado la escalabilidad: en las elecciones presidenciales de 2008 de Estados Unidos el máximo de tweets por segundo fue de 229; en la de 2012 ha sido 15,107 tweets por segundo.
A modo de curiosidad, comentar que en estas elecciones también se ha generado el tweet más retweeteado de la historia: Barack Obama le ha quitado el record a Justin Bieber con un tweet enviado la noche de la jornada electoral en la que decía "Four more years", y que incluía una fotografía del presidente abrazando a su mujer. La última vez que miré tenía más de 800,000 retweets.
Twitter, que inicialmente se consideraba como el principal caso de éxito de Ruby, se ha transformado en un caso de éxito para Java.
Reader Comments (8)
Ruby, como lenguaje, no es mejor ni peor gestionando la memoria. Todo depende del interprete del lenguaje, que es quien puede hacer mejor o peor esa gestión. Os recuerdo que ruby se puede también compilar en el bytecode de Java, aunque seguramente de forma no tan optimizada.
Yo conozco en persona a alguien que precisamente estaba trabajando en twitter intentando mejorar la gestión de memoria en la MV de Ruby, y, en sus propias palabras, estaba al nivel de las primeras versiones de Java, allá por finales de los 90.
Y no es "solo" por la máquina virtual. Si solo fuera eso, podrían haber migrado a JRuby mucho más fácilmente que migrar hacia Scala, Java y tsí, ambién JRuby. Pero bueno, como dicen: "haters gonna hate" así que siempre habrá gente que confunda herramientas con objetivos.
Intentaron con JRuby, pero al parecer tenían bastantes problemas, hay un hilo en Twitter aquí:
https://twitter.com/capotej/status/266295789435908097
Según pone, la generación de excepciones y compilación de clases en tiempo de ejecución eran problemáticas, siendo necesario apagar el JIT... No lo descartan para el futuro, pero por el momento no es viable.
Después de meterse en el proyecto de migración de Ruby a Java reconocieron que el problema no era del lenguaje, sino de la arquitectura que tenían montada
Y, porque el problema era la arquitectura,es el motivo por el que siguen la migración?
Sería interesante poder hacerle una entrevista... ¿Podremos conseguir algún developer de twitter para algún JavaHispano? (si hablara castellano tanto mejor!)
¿conoces a alguno? Aunque sólo sea de oídas; podemos contactar nosotros con el
@danwrong pero es muy de "front-end" (incluyo la parte servidor pero no creo que esté muy metido en el motor del proceso de mensajes)
Podeis leer algo suyo aquí:
http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html
Web: http://danwebb.net/