Los problemas de Twitter (y la escalibilidad)
Tal como me dice el recordatorio, hoy me toca hablar de Twitter. Pero no hablaré de si es una tontería mayúscula, de algo muy útil y de la revolución de las comunicaciones… eso que cada uno decida, yo también programo las mismas “tonterías”.
El tema viene del artículo y debate Twitter Problem, surgido a raíz de una entrevista a Alex Payne, uno de los desarrolladores de Twitter. Me llamó muchísimo la atención.
Un pequeño resumen de la entrevista y los temas que se comentaron:
- Twitter presume de ser el sitio más grande –supongo que por número de visitas y usuarios– con Ruby on Rails.
- Han elegido RoR por su facilidad de programación y porque vale “más el tiempo del programador” que los costes de servidores.
- Han tenido muchas dificultades (y siguen teniendo algunas) con al escalabilidad y la inaccesibilidad al web debido a estos problemas.
- Las limitaciones del RoR para sistemas distribuidos. No se puede trabajar –casi– con sistemas de bases replicados (parece que aún menos con los clusters active-active).
- Alex Payne afirma que fue un auténtico golpe pasar de programar en RoR a tener que preocuparse de los problemas “sucios” y de bajo nivel de la escalabilidad.
No me imaginaba que Twitter estaba en RoR, sobre todo teniendo en cuenta que su diseño de base de datos tiene que ser bastante simple, y su interfaz web es aún más sencilla.
Analizo el código fuente de su página pública y veo:
<!– served to you through a copper wire by sirin.twitter.com at 13 Apr 17:40 in 655 ms [1] (d 360 / r 253). thank you, come again. –>
[1] Cuando puse en marcha mi blog y ví que el WP tardaba casi el mismo tiempo casi me escandalizó y me decidí a programar el wp-cache. En una de las justificaciones que puse en wordpress.org dije que “WP is a pig” y cuando me encontré con Matt me dijo que me buscaba porque quería conocerme, sobre todo por esa frase :-).
Según el programa, ha tardado más 0.6 segundos en generar la página [1]. Ese número ya es bastante elevado, lo es aún más si se tienen muchas consultas simultáneas. Pero además lo pruebo desde el lado cliente, con el web:
- $ time wget -q http://twitter.com/public_timeline
y obtengo valores de tiempo real entre 1.5 y 8 segundos (lo mínimo que pude ver fueron 1.3 segundos). La media –sin contar los numerosos timeouts– estará entre 3 y 4 segundos.
En el menéame implementé hace un tiempo algo muy similar al Twitter, pero integrado con los usuarios y sus “relaciones” del menéame: el Nótame. Hago ahora las mismas pruebas con una página similar:
- $ time wget -q http://meneame.net/notame/
El tiempo máximo que obtengo son 0.4 segundos, con una media de 0.2 segundos.
Se podría argumentar que hay muchos menos datos que el Twitter, así que hice la misma prueba con la página principal del menéame, cuya base de datos es mucho más compleja, el HTML generado es bastante más grande y requiere muchas más consultas a la base de datos. Los resultados son bastantes similares, la media estará entre 0.25 y 0.35 segundos.
Claramente tienen un problema de rendimiento y tiempos de respuestas muy elevados. Twitter tenía al momento de la entrevista unos 16 cores y parece que están agregando nuevos servidores constantemente, el problema es aún más importante. Tal como mencionan en el apunte y la entrevista, los problemas fundamentales son dos:
- La elección del RoR.
- Problemas de escalabilidad derivado de las limitaciones del RoR (yo agregaría también que quizás la base de datos no esté del todo fina).
Es decir, el RoR es causa principal de los problemas y que durante varios días casi les dejó fuera del “negocio”.
Pero lo que no acabo de entender es el porqué se decidieron a usar el RoR para una web tan sencilla. Para que sirva como criterio de comparación, el Nótame que es muy similar tiene los siguientes ficheros:
- Librería básica: libs/post.php, 193 líneas (PHP)
- Interfaz web: sneakme/index.php, 133 líneas (PHP)
- Interfaz web móviles: mueveme/notame/index.php, 75 líneas (PHP)
- Backend Ajax e interfaz SMS (con servidor propio y de nviasms): 230 líneas (PHP)
- Interfaz jabber: 672 líneas (Perl)
- Generador RSS2 personalizable: sneakme_rss2.php, 117 líneas (PHP)
Eso nos da un total de sólo 1420 líneas contando vacías y comentarios –no le dediqué ni 20 horas de programación a todo el nótame–. Supongamos que el Twitter sea 5 veces más complejo –no lo creo–, ¿justifica esa simplicidad el uso de Ruby on Rails? Yo creo que no, es más, creo que ha sido un error que casi les cuesta el negocio.
El problema de rendimiento de RoR es claramente conocido. Ruby es más lento que Python, aún más que PHP. A eso hay que sumar la penalización enorme framework Rails (de hecho justo antes de comenzar con el Menéame estábamos trabajando en un proyecto RoR con la Banca March y por ello tenía ganas de usarlo en el Menéame, pero como comenté antes, no hubiese sido posible).
Entonces, ¿por qué lo usaron? Una de sus justificaciones en el “tiempo de programador”, pero ese tiempo ahorrado queda luego desperdiciado en solucionar los problemas de escalabilidad. Como dice el propio Payne:
The solutions to this are caching the hell out of everything and setting up multiple read-only slave databases, neither of which are quick fixes to implement. So it’s not just cost, it’s time, and time is that much more precious when people can[’t] reach your site. None of these scaling approaches are as fun and easy as developing for Rails.
Yo creo que han usado el RoR por una cuestión de moda, ahora mismo para ser cool en Silicon Valley hay que usarlo.
Por otro lado, las cifras que dan de Twitter no me impresionan demasiado. Hablan de unas 11000 peticiones por segundo en horas pico. Si se refieren a consultas a la BBDD, el Menéame está en unas 2000-3000 en horas pico (y unas 50-60 páginas por segundo). Si hubiésemos usado RoR quizás ahora mismo necesitaríamos unos 5 a 10 servidores web en vez del único que tenemos ahora. Es nos hubiese subido nuestros costes de los 300 euros mensuales a por lo menos 1500-2000 euros, lo que hubiese hecho imposible iniciarlo en el peor de los casos. O quizás a ceder más antes las ofertas publicitarias “intrusivas” –flash y gif supra-animados– que nos llegan cada día para poder pagar los gastos.
Es decir, quizás el RoR me hubiese ahorrado trabajo de programación y hubiésemos tenido más prensa “técnica”, pero eso hubiese significado más problemas de mantenimiento de una infraestructura más compleja, dinero para salarios para administradores de sistemas, etc. etc. etc, En una palabra, estoy convencido que no podríamos haber llegado hasta hoy, a menos que hubiésemos conseguido inversiones cuantiosas o endeudarnos hasta las orejas [2].
[2] Por su propia naturaleza –verificación de votos hasta para los anónimos–, no hay ninguna clase de caching en el Menéame, ni en el Nótame.
Pero el problema que veo es que a diferencia del It does not matter que quizás sea cierto en empresas tradicionales, pero en casos como estos –servicios web que necesitan mucha escalabilidad, además de ser líder– una mala decisión técnica te puede dejar fuera del negocio, o como mínimo perder oportunidades para dejárselas a los competidores.
Creo que Twitter es un buen ejemplo de que no hay balas de plata –con un PHP podrían haber solucionado el problema de forma muy limpia, como lo hicieron en Wordpress.com, que además es un sistema muchísimo más complejo y cargado–. Al final seguro que terminarán solucionando estos problemas particulares de Twitter (que además son relativamente simples) porque el RoR es software libre y su comunidad está muy interesada en atacar y solucionar esos problemas.
Pero también creo que será el ejemplo perfecto de que no hay que infravalorar los problemas de la escalabilidad y base de datos distribuidas, y que la mala elección de un lenguaje y sobre todo el framework –sólo porque está de moda– podría tirar al trasto con cualquier start up, aunque sea tan líder y tenga tanta “prensa” como Twitter.
Lo que se dice siempre, “morir de éxito”, pero ¡ostras!, aquí está claro que hubiese sido culpa de una “moda informática” –hoy se llama web frameworks– que se pretende usar para todo, incluso cuando sus desventajas para el caso superan con creces las ventajas.
Cuando la moda son los martillos, ¿todos los tornillos parecen clavos? 
PS: una vez escuché a EDans dar una [muy buena] clase sobre estos temas de plataformas, crecimientos y costes. Aunque no sé si entendería las diferencias entre frameworks [or lack thereof], lenguajes de scripting y bases de datos distrbuidas, me gustaría que opinase sobre el tema. RBA también tiene sistemas complejos programados en C, estaría bien que también cuente sus problemas.
“no podríamos haber llegado hasta hoy, a menos que hubiésemos conseguido inversiones cuantiosas o endeudarnos hasta las orejas”
Hay otra manera de paliar gastos: generar ingresos (entiendo que eso no siempre es posible, sobre todo cuando se empieza).
Sobre temas de escalación, etc. si algún día saco un poco de tiempo contaré mis éxitos y fracasos. El lenguaje a usar influye, aunque realmente uno no empieza a tocar temas de escalabilidad realmente serios hasta que empieza a añadir a su vocabulario términos como load balancing, MogileFS, SPOF, clusters, reemplazar MyISAM por InnoDB, etc.
Comment by RBA — Friday 13/4/2007 @ 22:27
> Hay otra manera de paliar gastos: generar ingresos
En web como menéame es difícil sin publicidad, y como no queremos caer en la publicidad intrusiva, cuesta aún más.
Pero en el caso de Twitter es aún peor, tienen que asumir hasta los costes de envíos SMS.
Comment by gallir — Friday 13/4/2007 @ 22:30
[…] post de Ricardo Galli en el que habla de los problemas que ha tenido Twitter debido a su espectacular crecimiento, y […]
Pingback by La cara técnica de Twitter at Tecnorantes — Friday 13/4/2007 @ 22:31
Problemas de escalabilidad en Twitter…
Ricardo Galli explica la importancia de elegir un lenguage que escale bien y no guiarse por las modas de cada momento.
En twitter parece que están teniendo problemas, precisamente por haber elegido RoR….
Trackback by coRank — Friday 13/4/2007 @ 23:39
Yo sigo creyendo en que RoR no es “tan” malo para el rendimiento…
Por ejemplo, pregunta a los de La Coctelera, que además de tener muchísimas peticiones al día hacen uso de bases de datos distribuidas… O a alguno de sus clientes que también usan Rails, como 20 minutos.
Evidentemente, tiene mayor precio de coste que PHp, pero no mucho más.
Comment by Víctor Pimentel — Friday 13/4/2007 @ 23:50
#5 Víctor, yo creo que sí, que es bastante peor (sobre todo por el Rail). Lo que pasa es que en muchos casos puedes fragmentar y distribuir las consultas fácilmente, por ejemplo por subdominios.
En el caso de la coctelera, veo que usan el lighttpd, así que seguramente hacen “caching” de casi todo (es relativamente sencillo para un blog, véase wp-cache :-).
En 20minutos no tengo idea, pero va muy rápido en tiempo de respuesta (0.55-0.60 segundos), así que si es RoR usan caching.
Comment by gallir — Friday 13/4/2007 @ 23:58
¿Quién ha escrito el post, Bambi?
Es curioso que un sitio tan sencillo tenga tantos problemas.
Comment by Demian — Saturday 14/4/2007 @ 0:21
Hombre, es que cachear es algo básico para una aplicación web de éxito…
El problema de Twitter es que su contenido es poco “cacheable”: el contenido se genera cada muy poco tiempo, está repartido por muchísimos sitios que son visitados por poca gente.
Mi opinión es que si hubieran usado PHP tendrían los mismos problemas que ahora, quizás algo menores, pero con las mismas consecuencias.
Ahora, si en vez de Rails o PHP utilizaran un lenguaje compilado quizás sí que les iría mejor
Comment by Víctor Pimentel — Saturday 14/4/2007 @ 0:46
¿Se puede escalar sin cachear? Me parece alucinante que siquiera dediques un segundo a planteártelo, claro que están usando cachés, como todo el mundo. De hecho creo que ellos sí que podrían dar LA clase sobre uso de cachés en Ruby on Rails (exportable a otros lenguajes de programación, oiga).
Cuando hablan de peticiones por segundo no creo que estén hablando de consultas a la base de datos, sino de peticiones HTTP, sinceramente, no creo que Menéame se pueda comparar (con todos mis respetos para Menéame).
Respecto a si Rails tiene problemas de rendimiento… es cuestionable. Está claro que si dejas que ActiveRecord haga lo que quiera vas a tener problemas de rendimiento (como con cualquier otro ORM).
En el caso de Twitter me inclino a pensar que el desastre se ha debido en gran parte a un desbordamiento de su *pequeñísimo* equipo de desarrollo, recuerdo por ejemplo que el script que actualizaba la página de usuario (una cosa similar a la Fisgona) hacía una request de todos los elementos, no sólo los últimos actualizados, un fallo de cajón, un fallo que del que seguramente no te puedes ocupar cuando estás muriendo de éxito.
Otra cosa es que Ruby sí tenga problemas de rendimiento, pero están en ello, vamos a darle una oportunidad, a mí personalmente me encanta programar en Ruby, cuando termina mi jornada laboral me siento mejor persona después de programar en Ruby
Comment by demimismo — Saturday 14/4/2007 @ 1:06
> ¿Se puede escalar sin cachear?
¡Claro que se puede! Para eso están (y se dedican tantos esfuerzos) los sistemas de base de datos master-slave, master-master, active-active, y sistemas de ficheros de clustering (con bases de datos sobre ellos, mira por ejemplo lo que dice RBA en #1). Y luego los proxies inversos para repartir carga, los heartbeats, etc. etc. o como en el mismo Twitter: “Mongrel cluster”.
Y no creo que Google o Gmail use caching tampoco, y escalan sobre unos 400.000 servidores.
> Me parece alucinante que siquiera dediques un segundo a planteártelo,
¿Ein? ¿Que debo pensar qué? ¿que sólo se puede escalar cacheando? Pues a ver, hum… no, hay otras formas
> claro que están usando cachés, como todo el mundo.
No, no todo el mundo usa cache, menéame no usa cache, digg tampoco usa cache (hasta donde yo sabía, por eso tiene como 100 servidores)
> Otra cosa es que Ruby sí tenga problemas de rendimiento
No es problema fundamental del Ruby (aunque me parece es un pelín más lento que el Python), sino fundamentalmente del Rails, que entre otras cosas –además de la carga impuesta por la capa MVC– no tiene buenas soluciones para clusters de bases de datos, por que tienen que usar sólo un servidor. Lo explican en la entrevista.
> En el caso de Twitter me inclino a pensar que el desastre se ha debido en gran parte a un desbordamiento de su *pequeñísimo* equipo de desarrollo
La aplicación de Twitter es extremadamente sencilla, es lo que explico y argumento en el artículo. El nótame hace casi lo mismo, y lo hizo _una_ persona en menos de 20 horas. No es problema de “falta de equipo de desarrollo”.
PS: respecto a las 11.000 peticiones, si fuesen HTTP daría unas 950 millones de páginas por día (de pico), más de 100 veces las páginas de Digg que es uno de los sitios con más tráfico web del mundo. No puede ser, aunque los dividas por cinco, te queda en 20 veces más que Digg.
Comment by gallir — Saturday 14/4/2007 @ 1:48
El Ruby on Rails no se elige ni por moda ni por rendimiento, se elige porque disfrutas como un guarro al desarrollar y al mantener. A los usuarios que les den, si se cansan de esperar que se vayan a otra parte. Qué pesados los usuarios, siempre pidiendo, siempre pidiendo… los programadores tambien tienen derecho a divertirse X’-DDD
Lo que tiene el RoR son muchos detalles (desde cosillas de bajo nivel hasta cosas gordas de arquitectura) que se cargan el rendimiento por defecto. Segurísimo que los de Twitter saben diez veces más que yo, pero por poner un ejemplo: configurando a mano y recompilando desde los últimos fuentes en lugar de usar los paquetes binarios de Debian (para SPARC64, que venian hechos una mierda, para mí que ni los probaron) pasé de 0.6 páginas por segundo a unas 200 páginas por segundo sobre la misma máquina, lo cual es bastante escandaloso. El hecho de usar Mongrel en lugar de Webrick como servidor HTTP marca una diferencia, y a partir de ahí hay mil cosas más que afinar. Pero vamos, que se pueda alterar el rendimiento dos o tres órdenes de magnitud en una tarde hace pensar que hay margen para el “tuning”…
El Ruby en sí, para empezar, es muy ineficiente en las versiones estables. A partir de la versión 1.9 mejora bastante, por lo que he podido probar de los repositorios. Por ejemplo hice un generador de espirales de Ulam en Ruby y con la versión 1.8 me tardaba del orden de tres cuartos de hora para generar una matriz que un programa en C pelado me hacia en segundos. Con la versión 1.9 (alpha o beta-algo) de Ruby la cosa bajó a pocos minutos, y las mejoras más espectaculares se reservan para la versión 2.0 con la máquina virtual nueva. Además, como el lenguaje es tan, tan, TAN bueno, y la implementación inicial es tan rematadamente mala, ahora mismo debe haber como siete u ocho proyectos de free software que lo reimplementan usando distintos enfoques. Es demasiado bueno para dejarlo tirado y precisamente por eso yo creo que tiene futuro
Comment by guillem — Saturday 14/4/2007 @ 2:45
¿Es incompatible cachear con balancear la carga o usar un sistema de almacenamiento más rápido? ¿he dicho yo que sólo se pueda escalar cacheando?
Repito, no digo en ningún sitio que sólo se pueda escalar cacheando, sencillamente que me parece algo imprescindible para escalar una aplicación web, decir que google o gmail no cachean es tan barato como decir que sí lo hacen, sencillamente no tienes datos.
Creo que el uso de cachés es un medio para reducir la carga y escalar de forma razonable, cuando he preguntado si se puede escalar sin cachear me refiero a escalar de forma sostenible (mea culpa, soy un vengador). Y ojo que hay muchas formas de cachear datos.
Ok, aquí me he colado. Quizá debí referirme a lo que hacemos los mortales
¿Dices que se ven obligados a poner 100 servidores porque no usan cachés?
buffer underrun
Esto es fundamentalmente lo que no me cuadra de tu razonamiento, ninguna aplicación con la carga de Twitter es sencilla, da igual que aparentemente sea sólo una cajita de texto. Nótame no se puede comparar fundamentalmente por esto, creo que lo sabes de sobra, no me hagas enlazar clones de otras aplicaciones
Seguramente uno puede ponerse una semana y sacar una cosa parecida a la Coctelera, otro asunto diferente es hacer un producto que pueda ser utilizado por un montón de gente. Me flipa esa tendencia a decir que lo que hace el prójimo es fácil.
No, a no ser que tú llames “pico” a 24 horas, yo llamo “pico” a una cosa de un par de segundos
De todas formas es cierto que son muchas, no se a qué se refieren en el artículo.
Comment by demimismo — Saturday 14/4/2007 @ 3:13
Se me olvidaba, no es lo mismo páginas que peticiones HTTP
Comment by demimismo — Saturday 14/4/2007 @ 3:26
Buenas,
“No es problema fundamental del Ruby (aunque me parece es un pelín más lento que el Python), sino fundamentalmente del Rails, que entre otras cosas –además de la carga impuesta por la capa MVC– no tiene buenas soluciones para clusters de bases de datos, por que tienen que usar sólo un servidor. Lo explican en la entrevista.”
que el framework no tenga soporte para conectar a varias bases de datos no significa que no se pueda hacer, si viniera de serie con ‘todas las cosas que hacen falta’ seria un monstruo. Un par de ideas de como afrontar el problema:
http://tinyurl.com/36twmo
http://tinyurl.com/2plnhs.
Ciao.
Comment by Antonio Pardo — Saturday 14/4/2007 @ 4:31
Bones Ricardo,
Vaig llegir l’article/entrevista i is us fixau hi ha un comentari de n’Adrian Holovaty (un dels creadors de Django) que els hi diu que haurien d’haver fer servir Django
Ruby és “cool” i tot el que volgueu, però quan un es planteja passar de PHP, com és el cas de Ricardo a Ruby o en el meu cas de Python a Ruby, el tema cool deixa de tenir importància front a temes com escalabilitat, rapidesa de manteniment i documentació i llibreries disponibles.
Però m’estic desviant del tema, :). Django té tot un capítol del seu llibre dedicat a l’escalabilitat: http://www.djangobook.com/en/beta/chapter21/
Potser no estarà tan de moda com Ruby, però la meva experiència personal és que és força divertit programar amb Python i Django, els recursos necessàries de màquina són mínims i la generació de les pàgines és molt ràpida. En les aplicacions que hem fet darrerament tot son lloances del ràpid que es veuen les pàgines vers pàgines semblants de la competència.
Segur que Ruby anirà evolucionant en el futur, però no per ser cool vol dir que sigui el millor. Llocs importants fets amb Python m’hi ha a potades, amb Django poedu veure’n una llista a http://code.djangoproject.com/wiki/DjangoPoweredSites fins i tot Tabblo recent comprat per HP està fet amb aquesta tecnologia.
Salutacions,
–
Toni
Comment by aaloy — Saturday 14/4/2007 @ 10:46
Guillem:
> pasé de 0.6 páginas por segundo a unas 200 páginas por segundo sobre la misma máquina
Esto es imposible, verifica el test, que lo más seguro es que esté dando un error en el servidor y por eso genera tantas “páginas”.
Demimismo
> ¿Es incompatible cachear con balancear la carga o usar un sistema de almacenamiento más rápido? ¿he dicho yo que sólo se pueda escalar cacheando?
No, no es incompatible, pero sí has dicho que no se puede escalar sin caching y casi tratándome de tonto por no pensar así: “¿Se puede escalar sin cachear? Me parece alucinante que siquiera dediques un segundo a planteártelo”
> Se me olvidaba, no es lo mismo páginas que peticiones HTTP
Las mayoría de las “otras” peticiones http de una página de twitter no _deberían_ pasar por RoR, son imágenes estáticas en su mayoría:
http://assets0.twitter.com/…/874380_1760555975.jpg?1176357269
(el ?1176357269 debe ser para evitar caches de navegador ¿¿??, porque no cambia nada).
Comment by gallir — Saturday 14/4/2007 @ 10:56
Tal y como yo lo veo, soy de la misma opinión que Ricardo, y considero que usaron RoR por moda. Es una de las premisas a la hora de hacer un proyecto Web 2.0 de éxito: atraer a los geeks para que te hagan márketing gratuito (con API’s… y con lenguajes/frameworks/cms’s “cool”). Y el márketing les está dando problemas técnicos, como pasa en cualquier sitio. La escalabilidad en un proyecto web lo dan lenguajes como PHP o Java, que por algo son los dos lenguajes más usados en el mundo. Pero siempre puedo hacer una web en BASH, y que el mundo hable de lo cool que soy.
Jaiku.com está hecho en PHP 5, servido por un Apache 2, en una Fedora… no es muy cool que digamos… Pero es mucho mejor, más rápido, y seguro que tienen muchísimos menos problemas técnicos, y muchísimos menos costes econímicos. Jaiku saldrá adelante, y lo hará más rápido que Twitter. De hecho ya les ha comido mucho terreno. ¿Dónde está “el tiempo del programador”?
Comment by Javier Pérez — Saturday 14/4/2007 @ 14:12
Twitter no es el único que tiene problemas de escalabilidad con RoR, La Coctelera también. En cuanto a las estadísticas que has hecho, ¿no habría que tener en cuenta la latencia de red? Por cierto, que con acelerador, PHP es bastante más rápido ya que no tiene que interpretrar las librerías en cada petición. Eso y una caché, son manos de santo. En Blogalia hay bastante middleware y para servir en dinámico sin acelarador no hay alternativa.
Comment by rvr — Saturday 14/4/2007 @ 15:48
Por cierto, que hace tiempo escribí sobre esto en mi bitácora de Barrapunto: Por qué Rails no se comerá a PHP.
Comment by rvr — Saturday 14/4/2007 @ 15:59
[…] CesarS, clasificado en: minipost, webmaster Los problemas de Twitter (y la escalibilidad) agregar a del.icio.us » | menéalo » […]
Pingback by backdraft » Archivo » Los problemas de Twitter (y la escalibilidad) — Saturday 14/4/2007 @ 17:17
Ricardo, creo que la conversación se nos está saliendo del tiesto, pero quiero aclarar un tema.
No, no te estaba tratando de tonto, y te pido disculpas si mis palabras han sonado mal, pero comprende que tú sí que tratas de tontos al resto de la gente que usamos Rails cuando dices que lo hacemos por “moda”.
Sinceramente, yo me siento insultado porque es la herramienta que uso ahora para trabajar y creo que lo hago por una decisión consciente, no por moda.
Y me jode más aún que lo escribas tú en tu blog super popular porque luego tendré que escuchar a un montón de gente rebuznándome lo mismo cada vez que les diga que trabajo con Rails, de ahí mi cabreo.
Comment by demimismo — Saturday 14/4/2007 @ 22:36
demimismo, creo que te lo has tomado demasiado mal, no digo que “todos”, sino que en este caso en particular yo no encuentro justificación para un RoR si estás por hacer un sitio tan sencillo y simple como el twitter, pero que tiene que escalar muchísimo.
El RoR es _muy_ bueno, pero no es la solución mágica para todo, y más allá que esté de moda hay que analizar si es la mejor opción. Evidentemente no ha sido lo mejor para Twitter.
Comment by gallir — Saturday 14/4/2007 @ 22:40
Varios comentarios:
- Igual que Meneame tiene una historia, Twitter tiene la suya. Twitter fue un side-project de Odeo. Un experimento. Arrancaron con Rails porque es la herramienta que usaban (y lo llevaban usando mucho tiempo, antes de que nadie pudiese decir que RoR estuviese “de moda”), y en tres meses el crecimiento ha explotado, que es cuando han empezado a tener problemas. Twitter ha funcionado de manera normal sin absolutamente nada de caché durante muchos meses y con muchos usuarios. En mi opinión han tardado bastante en cachear, cosa que si hubiesen hecho antes probablemente no estaríamos hablando de ellos.
- Me parece un tanto infantil el “estás conmigo o estás contra mí” que supone el descalificar RoR como herramienta, afirmar categoricamente que PHP es mejor, y que elegir RoR es un problema en si mismo. RoR tiene muchas cosas interesantes, e inconvenientes claros (fundamentalmente, el overhead de utilizar un framework y la velocidad de Ruby) de los que cualquier desarrollador responsable es perfectamente consciente cuando toma la decisión de utilizarlo.
Asímismo, tampoco tiene sentido decir que RoR es lo mejor, y que todo lo demás sobra. Cualquier persona con sentido común y una mínima visión histórica nunca dirá algo así. Cada uno prueba herramientas, y utiliza la que más le compensa después de un analisis racional. Creo que ya estamos mayorcitos para andar con peleas de lenguajes y herramientas atacando al tema del rendimiento.
- Modas: ¿qué ha llevado a RoR a “estar de moda”? ¿Grandes campañas publicitarias? ¿Ser el título del último disco de Britney Spears? ¿Aparecer en el telediario de las 9? Si la gente habla de RoR es porque hay desarrolladores que lo han probado y les ha resultado interesante. Decir que la gente usa RoR porque está de moda me parece una falta de respeto a la inteligencia de la gente ha decidido usar RoR (igual que me parece una falta de respeto descalificar cualquier lenguaje porque sí).
- Escalando: ¿Meneame aguantará toda la vida en un único servidor? Si sigue creciendo, no. ¿Qué harás cuando llegue ese día? Hay muchas estrategias (cachear la primera, antes de pasar a estar en dos máquinas). Tendrás que tomar decisiones y picar código para implementarlas. Lo mismo que harías con Rails. Es cierto que con Rails necesitas más capacidad de proceso, pero los problemas a los que te enfrentarás serán exactamente lo mismos, y las soluciones para atajarlos serán también las mismas (aunque con Rails lleguen, objetivamente, antes).
¿Qué tendrías que hacer para que Meneame utilizase, por ejemplo, un esquema de DB maestro-esclavo? Programarlo. ¿Que hemos hecho en La Coctelera cuando lo hemos necesitado? Programarlo. Por cierto, han sido poquísimas lineas de código (vamos a publicar como lo hemos hecho, a raiz de esta polémica). No sé cúanto costaría hacerlo en Meneame.
- Respecto a lo que comenta rvr sobre los problemas de escalabilidad de La Coctelera, es cierto que los hemos tenido, pero parece que ya están superados
- InnoDB vs. MyISAM: Otro posible factor por el que una aplicación tenga un rendimiento inferior a otra. Si usas MyISAM vas más rápido, pero si tienes problemas, tus problemas serán mucho mayores. Veo en el CVS que Meneame usa MyISAM, has valorado pasar a usar InnoDB?
saludos
álvaro
Comment by álvaro — Saturday 14/4/2007 @ 23:41
#22.
> Me parece un tanto infantil el “estás conmigo o estás contra mí”
No dije eso.
> supone el descalificar RoR como herramienta
Tampoco lo dije. Insisto: digo que “no hay bala de plata”, lo que significa que un lenguaje/framework no es la solución para todos los problemas. Mira el #21.
> Creo que ya estamos mayorcitos para andar con peleas de lenguajes y herramientas atacando al tema del rendimiento.
La pelea la estás creando tú. Parece te ha molestado, en ningún momento dije que el RoR no sirva ni que la solución de la coctelera sea mala (creo que todo lo contrario).
> Modas: ¿qué ha llevado a RoR a “estar de moda”?
El Ruby está muy bien, el Rail también y has sido uno de los primeros MVC para web que salió. Además es libre. Y supongo que otros factores aleatorios, el buzzword y el apoyo de unas empresas (como ha pasado con el Java)
> Escalando: ¿Meneame aguantará toda la vida en un único servidor?
Seguramente no. Ojalá.
> Es cierto que con Rails necesitas más capacidad de proceso, pero los problemas a los que te enfrentarás serán exactamente lo mismos,
No, no son los mismos. Porque no usamos framworks, que limitan lo que puedes hacer. En el caso del menéame ya está pensado.
> Si sigue creciendo, no. ¿Qué harás cuando llegue ese día? Hay muchas estrategias (cachear la primera, antes de pasar a estar en dos máquinas)
Cachear no tiene sentido, comenzaremos con tener varios servidores webs con la BBDD centralizada. Luego replicaremos la BBDD si hace falta con un master-slave. Ya tengo abstracción de bbdd modificada y probada, es un array con el master y los slaves, si el sql es algo distinto a un select (la regexp ya lo hace) se usa el maestro, sino un random entre los esclavos y el maestro (si hace falta).
> ¿Qué tendrías que hacer para que Meneame utilizase, por ejemplo, un esquema de DB maestro-esclavo?
Menos de 10 líneas líneas en el fichero ezdb1-simple.php para hacer lo anterior (que ya está probado, pero falta mucho tiempo para llegar a ello).
Comment by gallir — Sunday 15/4/2007 @ 0:34
> La pelea la estás creando tú. Parece te ha molestado, en ningún momento dije que el RoR no sirva ni que la solución de la coctelera sea mala (creo que todo lo contrario).
Bueno, en el post dices de forma bastante tajante que el problema de Twitter es la elección de RoR, cosa que en mi humilde opinión no tiene mucho sentido. Pero en cualquier caso, disculpa si mi tono ha sido demasiado altisonante.
> No, no son los mismos. Porque no usamos framworks, que limitan lo que puedes hacer. En el caso del menéame ya está pensado.
Los problemas de escalar una aplicación web no tienen que ver con las herramientas que estés utilizando. Lo que si tiene relación es la forma en que los solucionarás, pero los problemas si son los mismos: que el servidor web no pueda servir tanto, que la BD no pueda resolver tantas queries, que el servidor de aplicaciones no pueda procesar tantas peticiones, etc.
Depende del framework que uses, conseguir que tu aplicación obtenga alguna funcionalidad que no trae de serie será más fácil o complicado, como tu dices, limitarán lo que puedes hacer. En el caso de hacer un esquema DB maestro-esclavo, tu dices que te ha costado menos de 10 lineas. A nosotros con Rails nos ha costado también muy poco (vamos a publicar como lo hemos hecho con todos los detalles, pero no se si habían sido 6 lineas de código). A lo mejor es que Rails está bien pensado y en vez de plantearte limitaciones permite que lo extiendas de acuerdo a tus necesidades de forma sencilla.
Por otro lado cuando empiezas a tener más de una máquina te surjen nuevos problemas, tanto con framework como si él, que no existen cuando tienes una sola.
Depende del proyecto que tengas entre manos, también surjen determinados requisitos que te obligan a utilizar varias máquinas…
Comment by álvaro — Sunday 15/4/2007 @ 1:26
> Bueno, en el post dices de forma bastante tajante que el problema de Twitter es la elección de RoR,
Lo dijo el programador de Twitter en primer lugar, y los problemas que han tenido son reales, existieron y siguen existiendo. Primero reflejo sus palabras y esos hecho y luego explico porqué estoy de acuerdo en que el RoR fue una mala elección. Pero es que además no lo digo en el aire, pongo algunos números, de programas más o menos similares en otro lenguaje y mediciones de tiempo.
Y repito: dada la sencillez de Twitter (en web y bbdd) y su problema fundamental que era escalar a millones de usuarios, la elección de RoR fue errónea. Citando a Brooks, “there is no silver bullet”, y este es un ejemplo.
Esos es todo lo que dije, también comenté que en la UIB estábamos trabajando con RoR en un convenio de la Banca March… y por si no quedó claro, lo elegí yo para esa aplicación (pero que nunca llegará a tener más de unas pocas miles de visitas diarias, con mucha suerte).
> Por otro lado cuando empiezas a tener más de una máquina te surjen nuevos problemas, tanto con framework como si él, que no existen cuando tienes una sola.
Los problemas son distintos, en algunos es muy fácil solucionar el tema de bbdd replicados, en otros –como el caso de RoR– se hace mucho más complicado si usas el ActiveRecord (que es lo que usan).
> En el caso de hacer un esquema DB maestro-esclavo, tu dices que te ha costado menos de 10 lineas.
¿Y cómo es que Twitter siendo tan sencillo ha tenido tantos problemas? No me cuadra (aunque tampoco me cuadra que no estén usando caching en esas páginas que probé, al menos de unos pocos segundos de “vida”… o lo usan pero también les va muy lento).
Tampoco me cuadra que se tome casi un segundo en generar una página muy simple (es lo que se toma). Esos tiempos no son nada adecuados para un servidor web, donde los procesos del servidor se acumulan a lo bestia.
Comment by gallir — Sunday 15/4/2007 @ 1:50
Por cierto, acabo de ver:
http://laughingmeme.org/2007/04/12/twitter-ruby-and-scaling/
Un desarrollador de Flickr:
1. Ruby is dead slow. This is not news, though it can be surprising when you’re used to thinking about scripting languages as all being roughly equal.
2. Rails trades developer performance for framework performance. Also not news, as this has been the mantra of Rails since day 1.
Otra visión: http://tomayko.com/weblog/2007/04/13/rails-multiple-connections
Bottom line for me is that Twitter’s scaling and multi-database connection issues seem to be just that: Twitter’s issues.
Comment by gallir — Sunday 15/4/2007 @ 2:22
Por aquí dicen los de Twitter que darán una conferencia sobre cómo escalar con Rails. Será el 21/22 Noviembre, visto aquí:
http://romeda.org/blog/2007/04/scaling-twitter-talk.html
Pondrán también slides y posiblemente audio, a ver si así queda todo más claro.
Salut!
Comment by kota — Sunday 15/4/2007 @ 4:26
> ¿Y cómo es que Twitter siendo tan sencillo ha tenido tantos problemas?
Bueno, son problemas de Twitter, pero no de Rails. Si usas Rails sabes que tendrás que cachear no demasiado tarde, y parece que ellos no han sido lo suficientemente rápidos (aunque su historia de crecimiento me temo que no tiene comparación posible).
> Un desarrollador de Flickr
Es perfecto que saquemos como ejemplo Flickr, porque ellos ahora funcionan perfectamente, pero estuvieron meses con problemas graves de rendimiento, páginas que tardaban 10-15 segundos en cargarse o que directamente no cargaban. O sea, que problemas de rendimiento y escalabilidad los tiene cualquiera, con el lenguaje que use y use o no framework (como sabéis Flickr también es una aplicación en PHP hecha de cero por ellos mismos).
Respecto a la cuestión de Twitter no necesita un framework como Rails por su simplicidad, he tratado de contar la historia: fue un experimento paralelo totalmente secundario en el que resulta que luego se han centrado, y cuyo crecimiento ha explotado. Hace podrían haberse parado a plantearse el cambiar de lenguaje y reescribir el código en algo más rápido, o neutralizar los cuellos de botella que tenían. Han optado por lo segundo, que es la opción por la que hubiese optado casi todo el mundo en su caso.
Insisto en que mi conclusión es que aunque haya lenguajes más rápidos que otros, las cuestiones de escalabilidad a las que te enfrentarás son las mismas con o sin framework, y al menos en el caso de Rails no te encuentras limitado sino que ampliar la funcionalidad del framework es algo suave, sencillo, y rápido. Al menos si conoces la herramienta lo suficiente (que no se si será el caso del citado desarrollador de Twitter).
¿Alguien utilizaría tecnología de Microsoft para hacer un sitio como MySpace? Da vértigo de solo pensarlo, eh?
Comment by álvaro — Sunday 15/4/2007 @ 10:41
La semana en los blogs LXXII…
…
Trackback by Error500 — Sunday 15/4/2007 @ 11:26
Los problemas de Twitter (y la escalabilidad)…
Tal como me dice el recordatorio, hoy me toca hablar de Twitter. Pero no hablaré de si es una tontería mayúscula, de algo muy útil y de la revolución de las comunicaciones… eso que cada uno decida, yo también programo las mismas “tonterías…
Trackback by meneame.net — Sunday 15/4/2007 @ 15:55
#28: ¿Alguien utilizaría tecnología de Microsoft para hacer un sitio como MySpace? Da vértigo de solo pensarlo, eh?
Siempre pensé que era algun acuerdo comercial, porque técnicamente da problemas que me recuerdan mucho a los de Orkut, otro lugar con la tecnología de Microsoft.
MySpace es un lugar raro, no puedes escribir la / final tras la dirección de alguien, ni reenvia bien tras un login. Fue imposible dar de alta una cuenta durante muchos días seguidos –casi una semana. Busqué el error en Internet y había centenares de casos.
Hice el alta para probar el lugar, a ver qué tiene. Técnicamente nada, y las herramientas són más secas que un piojo de peluca. Lo que tiene es la comunidad, que les soporta con paciencia para estar en contacto con sus amigos. Por esto me imagino que el acuerdo es comercial, porque hagan lo que hagan esta comunidad seguirá ahí. Deberían estar caídos 15 días seguidos para que se largaran, y esto no sucederá.
Comment by Benjamí — Sunday 15/4/2007 @ 18:51
Scaling to multiple databases with Rails
http://www.loudthinking.com/arc/000610.html
Nic Williams has released Magic Multi-Connections. It makes it dead easy to use a cluster of databases to scale read and write speeds higher than a single connection would ever allow. (…)
Now how could this be. How could Nic fix such an apparent “critical flaw”, as others have billed the lack of this facility in Rails, in such a short time? Simple, he did it in less than 75 lines of Ruby as a plugin for Rails. Less than 75 lines.
In my mind, that’s the crux of the story. That extending Rails to do what you want is often much simpler than you think. That you can’t compare extending a high-level framework written in a language like Ruby to, say, patching Apache or MySQL. The barriers of entry are simply not in the same sport.
So let’s use this occasion to celebrate the wonders of open source (”some times you can just ask and you will receive”), but at the same time keep the effort involved in this example as a guidance for the future (”maybe next time, I could just have a look at how hard it would be to fix myself”). And of course, a big thanks to Nic Williams to making a big fuss a non-issue.
Comment by álvaro — Sunday 15/4/2007 @ 21:02
Hace dos años o así, Microsoft manejaba toda su red de messenger mundial con tan solo 16 servidores opterones. Vale que ahí no manejan base de datos, pero da una idea de lo que se puede hacer optimizando los recursos, que un sistema tan simple como lo es twitter tenga tantos problemas…es cosa de chiste
Comment by Diego — Tuesday 17/4/2007 @ 0:03
“Lo que se dice siempre, “morir de éxito”, pero ¡ostras!, aquí está claro que hubiese sido culpa de una “moda informática” –hoy se llama web frameworks– que se pretende usar para todo, incluso cuando sus desventajas para el caso superan con creces las ventajas.”
Totalmente de acuerdo.
Comment by Iñigo Medina García — Tuesday 17/4/2007 @ 10:45
La polémica sobre la escalabilidad de Rails…
…Entrevista con Alex Payne, uno de los desarrolladores de Twitter
Los problemas de Twitter ……
Trackback by Sugerencia de presentación — Tuesday 17/4/2007 @ 12:22
[…] Desde el punto de vista del usuario, Jaiku parece más rápido que Twitter (está desarrollado sobre PHP y no Ruby On Rails, lo que lo hace a priori más rápido); sin embargo no creo que llegue a tener más éxito que Twitter, a pesar de lo que opina Gallir. […]
Pingback by Exocert.com » Twitter y Jaiku — Tuesday 17/4/2007 @ 16:06
Sólo quiero dejar un enlace que puede aportar un granito más de arena a este buen hilo
Magic Multi-Connections allows you to write your models once, and use them for multiple database Rails databases at the same time. How? Using magical namespaci
http://magicmodels.rubyforge.org/magic_multi_connections/
Comment by Xavier Belanche — Tuesday 17/4/2007 @ 18:00
[…] Fajro me manda un post de Ricardo Galli que apunta en el mismo sentido. Guardado por David de Ugarte en el blog de feevy a las 9:05 pm […]
Pingback by » Ruby y la burbuja deUgarte.com — Wednesday 18/4/2007 @ 23:59
[…] los gana Twitter. A pesar de los problemas técnicos. Ricardo Galli detectaba problemas de funcionalidad en Twitter derivados de haber escogido mal el lenguaje con que se […]
Pingback by despuesdegoogle » Archivo del weblog » Twitter gana a Menéame — Thursday 19/4/2007 @ 12:39
Hola Ricardo, los problemas que planteas con el uso de RoR en una aplicación con tanto trafico, ¿se podrían haber evitado con el uso de un framework basado en php como puede ser Symfony o CakePHP?, ¿que opinas de estos?, ¿Ves a Symfony como una alternativa a RoR?
Comment by Ardic — Thursday 19/4/2007 @ 13:07
[…] el blog de Ricardo, me encuentro con que la gente de twitter está teniendo problemas para soportar el inmenso […]
Pingback by Twitter, y el retorno de la inversión? | Kabytes — Thursday 19/4/2007 @ 16:17
#41, hola ardic,
no tengo idea, quizás con PHP hubiese ido algo mejor.
Puede ser que yo lo vea de una forma muy rara, pero si esperaba tener tantos accesos (lo buscaban), no se me hubiese ocurrido hacer una aplicación tan sencilla con un framework que se sabe consume mucho de CPU (carga muchísimo) y que además tiene (o tenía, han propuesto una posible solución) para bases de datos distribuidas.
Comment by gallir — Thursday 19/4/2007 @ 17:22
[…] Me enlazan www.superrisas.com sentidoweb.com spanish.martinvarsavsky.net mnm.uib.es n0xtrum.blogspot.com […]
Pingback by Twitter y Jaiku: el nuevo networking | Javier Pérez :: Blog — Thursday 19/4/2007 @ 17:50
#43, Gracias de todas formas Ricardo. ¿Algún lector de este blog podría contestarme?
Comment by Ardic — Friday 20/4/2007 @ 19:12
[…] Twitter, mucho se ha escrito sobre lo que puede considerarse el fenómeno de la web en el primer trimestre de 2007. A pesar de empezar a funcionar a finales del verano pasado ha sido ahora cuando ha aumentado el número de usuarios, mostrando su verdadera utilidad (¿?) y sus carencias. […]
Pingback by Aplicaciones 2.1 at Mareos de un geek — Tuesday 24/4/2007 @ 15:44
[…] en ROR y como leí hace un mes más o menos lo que decia Ricardo Galli acerca de twitter en su post Los problemas de Twitter (y la escalibilidad): “* Twitter presume de ser el sitio más grande –supongo que por número de visitas y […]
Pingback by Twitter y como día a día una idea va muriendo. by Saturn Attacks — Wednesday 16/5/2007 @ 18:00
[…] ir más lejos, Twitter estuvo caído media mañana. El creador de Menéame, Ricardo Galli, escribió un artículo interesante al […]
Pingback by liboh.es » Twitter, el pequeño capricho — Saturday 9/6/2007 @ 6:23
[…] Sus problemas de carga en el servidor. […]
Pingback by Empezando con CakePHP | Michoacano.Com.Mx — Tuesday 12/6/2007 @ 1:14
[…] ya 2 meses que hicieron una entrevista a este desarrollador de Twitter, Alex Payne; y se montó una buena discusión en el blog de Ricardo Galli que en resumen criticaba el uso de Ruby On Rails para algo tan simple como […]
Pingback by eConectados » Twitter moviéndose a Django (Python) — Wednesday 13/6/2007 @ 10:46
[…] Aquí os dejo un articulo de Ricardo Galli sobre el motivo de los problemas de […]
Pingback by drosophilatec.net » Archivo del weblog » Corta vida para los proyectos en la web 2.0 — Thursday 14/6/2007 @ 2:10
He descubierto que Twitter, lo han traducido al español en la pagina Twittear.com
Comment by Jorge Comarrubias — Saturday 30/6/2007 @ 21:56