Los dolores de Ruby On Rails

Una entrevista con un desarrollador de Twitter, que habla de las
partes menos bonitas de RoR. Será especialmente interesante si
comentan otros que han sufrido el infierno de la escalabilidad
(¡Blat!, ¡Nando!, ¡Sergio! … :slight_smile:

http://www.radicalbehavior.com/5-question-interview-with-twitter-developer-alex-payne/


By various metrics Twitter is the biggest Rails site on the net right
now. Running on Rails has forced us to deal with scaling issues -
issues that any growing site eventually contends with - far sooner
than I think we would on another framework.

The common wisdom in the Rails community at this time is that scaling
Rails is a matter of cost: just throw more CPUs at it. The problem
is that more instances of Rails (running as part of a Mongrel
cluster, in our case) means more requests to your database. At this
point in time there’s no facility in Rails to talk to more than one
database at a time. 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. All the convenience methods and syntactical sugar that
makes Rails such a pleasure for coders ends up being absolutely
punishing, performance-wise. Once you hit a certain threshold of
traffic, either you need to strip out all the costly neat stuff that
Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move
the slow parts of your application out of Rails, or both.

It’s also worth mentioning that there shouldn’t be doubt in anybody’s
mind at this point that Ruby itself is slow. It’s great that people
are hard at work on faster implementations of the language, but right
now, it’s tough. If you’re looking to deploy a big web application
and you’re language-agnostic, realize that the same operation in Ruby
will take less time in Python. All of us working on Twitter are big
Ruby fans, but I think it’s worth being frank that this isn’t one of
those relativistic language issues. Ruby is slow.


Manuel, que
piensa que eres una excelente persona y medra en torno a
http://simplelogica.net y/o simplelogica.net
Recuerda comer mucha fruta y verdura.

El Apr 12, 2007, a las 4:37 PM, mort
escribió:

Una entrevista con un desarrollador de Twitter, que habla de las
partes menos bonitas de RoR. Será especialmente interesante si
comentan otros que han sufrido el infierno de la escalabilidad
(¡Blat!, ¡Nando!, ¡Sergio! … :slight_smile:

radicalbehavior.com is available for purchase - Sedo.com
developer-alex-payne/

Hubo replica aqui:

http://www.loudthinking.com/arc/000608.html

– fxn

On 13/04/07, Xavier N. [email protected] wrote:

El Apr 12, 2007, a las 4:37 PM, mort escribió:
Hubo replica aqui:

http://www.loudthinking.com/arc/000608.html

Sí, he visto ya varias réplicas. En principio parece que lo
másrazonable está a medio camino entre los problemas de Ruby/Rails que
explica Alex y el “realmente, ¿no pensarías que escalar algo como
Twitter fuera coser y cantar, verdad?”


Manuel, que
piensa que eres una excelente persona y medra en torno a
http://simplelogica.net y/o simplelogica.net
Recuerda comer mucha fruta y verdura.

Si… todas las quejas de Alex son completamente ciertas… el
problema no es que tan dificil sea escalar en Ruby o en Rails… el
problema es que escalar algo para manejar 11,000 solicitudes por
segundo es, y me perdonan el frances, fucking dificil.

En el post de Loud Thinking hay un comentario de Alex al final, un
poco molesto por el tono del post, pero indicando que por un lado no
se han quedado con los brazos cruzados, y que si piensan mejorar
ciertas cosas y devolverlas a la comunidad, y por el otro lado, que
aun con estos problemas estan contentos con rails pues a la hora de
resolver estos problemas de escalabilidad tienes mas opciones y
herramientas (y alex dice que tambien tiene experiencia escaland django)

En fin, que toda esta discusion es, como de costumbre, uno de esos
casos en donde los que odian rails ven mil razones mas para seguir
odiandolo, y los que aman rails ven mil razones mas para seguir
amandolo.

“At this point in time there’s no facility in Rails to talk to more than
one
database at a time. 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.”

UF,UF, Y UF

El Friday 13 April 2007 13:12:44 Xavier N. escribió:

Hubo replica aqui:
http://www.loudthinking.com/arc/000608.html

las propuestas no tardan en llegar:

Magic Multi-Connections: A “facility in Rails to talk to more than one
database at a time”
http://tinyurl.com/36twmo

ciao

mort
escribió:> Una entrevista con un desarrollador de Twitter, que habla de las

partes menos bonitas de RoR. Será especialmente interesante si
comentan otros que han sufrido el infierno de la escalabilidad
(¡Blat!, ¡Nando!, ¡Sergio! … :slight_smile:

aupa!

pues yo nunca he asociado estos dolores a Rails sino más bien a mis
limitaciones como administrador de sistemas, a errores (nuestros) de
diseño (o diseños mejorables en lo que a rendimiento se refiere) y, por
qué no decirlo, al éxito (un sitio con pocas visitas posiblemente no
tiene que preocuparse de escalar).

mi opinión es que Rails simplemente está hay, como una pieza más de tu
plataforma (que por otra parte hace bastante bien lo que tiene que
hacer), tan culpable o menos de sus limitaciones para escalar que
cualquier otra. la mayoría de las mejoras que hemos ido incorporando
para poder asumir más carga han estado relacionadas con esas otras
piezas (mysql, memcache, nfs, etc.) y no con Rails.

me pregunto si con otros frameworks podemos, por ejemplo, decirle a
nuestra aplicación que tiene dos servidores de bbdd que queremos que
trabajen como maestro y esclavo y no tener que preocuparnos por
configurarlos, monitorizarlos, recuperarlos en caso de caída, etc.

parte de la gracia de Rails le viene porque no se mete en camisas de
once varas. Dice hasta aquí llego y ofrece opciones para configuraciones
con distintos requisitos de rendimiento (como con la cache o las
sesiones) entre las cuales podemos incluso meter una de cosecha propia
gracias a su buena separación por capas.

muy posiblemente si pretendiese llegar a todos los sitios seguro que a)
se ataría a tecnologías concretas con las estariamos obligados a tragar
y b) no sería tan limpio y chulo :wink:

bueno, este es un tema que persigue a Rails desde que nació, pero yo
sigo insistiendo en que hablar de “la escalabilidad de un framework” es
similar a hablar de “el alpinismo en la estepa castellana”: se pueden
decir cosas, pero pocas interesantes en realidad.

salu2!
nando

is that more instances of Rails (running as part of a Mongrel
makes Rails such a pleasure for coders ends up being absolutely
will take less time in Python. All of us working on Twitter are big
Ruby fans, but I think it’s worth being frank that this isn’t one of
those relativistic language issues. Ruby is slow.


Fernando García Samblas
[email protected]

The Cocktail
C/ Salamanca 17
28020 Madrid
+34 91 567 06 05

On 4/12/07, mort [email protected] wrote:

Una entrevista con un desarrollador de Twitter, que habla de las
partes menos bonitas de RoR. Será especialmente interesante si
comentan otros que han sufrido el infierno de la escalabilidad
(¡Blat!, ¡Nando!, ¡Sergio! … :slight_smile:

Al final hemos escrito un pequeño paper contando cómo solucionamos el
tema concreto de la base de datos (que tampoco tiene mucha historia,
con Rails da gusto =;-) ), os lo podéis bajar de
http://www.lacoctelera.com/porras/post/2007/04/17/la-polemica-sobre-escalabilidad-rails


Sergio Gil Pérez de la Manga
e-mail > [email protected]
blog > http://www.lacoctelera.com/porras

On Friday 13 April 2007 12:59:39 Sebastian D. wrote:

resolver estos problemas de escalabilidad tienes mas opciones y
herramientas (y alex dice que tambien tiene experiencia escaland django)

Kevin C. ha puesto un poco de cordura[1] en esta discusión que se había
salido de madre con la respuesta (a la defensiva desde el punto de vista
de
muchos, el mío incluido) de DHH.

[1]
http://glu.ttono.us/articles/2007/04/15/on-twitter-rails-and-community

Saludos.


Imobach González Sosa
correo-e: imobachgs en banot punto net
jabber id: osoh en jabberes punto org
web: banot.net - banot Resources and Information.
blog: http://devnull.blogs.banot.net/

On Apr 17, 2007, at 12:34 PM, Sergio Gil Pérez de la Manga wrote:

escalabilidad-rails
Cojonudo Sergio! Muchas gracias a todo el equipo.

On 4/17/07, Xavier N. [email protected] wrote:

Cojonudo Sergio! Muchas gracias a todo el equipo.

Bueno, a ver si te sigue gustando después de leerlo =;-) No deja de
ser un hack, y no demasiado elegante, pero es tremendamente simple de
implementar, y funciona a la perfección. La verdad es que nos
sorprendió bastante todo el mogollón =:-S


Sergio Gil Pérez de la Manga
e-mail > [email protected]
blog > http://www.lacoctelera.com/porras

Hola!

Muchas gracias por compartir esa informacion. Lo que pasa es que a mi me
surge una duda.
Nosotros estamos utilizando varias bases de datos tambien, pero no para
escalar Ruby, sino para implementar una misma aplicacion contra diversas
bases de datos, según el usuario conectado.
Trasteando con Rails llegue a la misma conclusion que vosotros y, de
hecho, nuestra implementacion es exactamente igual a la vuestra, lo
unico que la logica que nosotros implementamos es discernir el DNS de la
url para saber a que base de datos conectarse. Aparte de que nuestras
bases de datos no son replicas.
Como bien decis en vuestro articulo, antes de procesarse el request,
Rails ya ha hecho una conexion. Segun nuestras pruebas, utilizando el
sistema que comentais, Rails hace 2 conexiones por request y eso se
traduce en un rendimiento de proceso entre un 20% y un 30% peor por
request.
Os pasa a vosotros esto? Esa perdida de rendimiento es algo achacable a
nuestra arquitectura? Merece la pena esa perdida? Habria alguna manera
de evitar que haga esa primera conexion? …?

De nuevo, muchas gracias!!
Un saludo
Roberto M. Oliva

El mar, 17-04-2007 a las 13:08 +0200, Sergio Gil Pérez de la Manga
escribió:

On Apr 17, 2007, at 1:23 PM, Roberto M. Oliva wrote:

Os pasa a vosotros esto? Esa perdida de rendimiento es algo
achacable a
nuestra arquitectura? Merece la pena esa perdida? Habria alguna manera
de evitar que haga esa primera conexion? …?

Posiblemente, establecer una conexion a base de datos es caro.

El dispatcher establece la conexion al principio y usa siempre la
misma. En cada peticion ejecuta

ActiveRecord::Base.verify_active_connections!

muy al principio, antes incluso de resolver la ruta. (Observa que el
nombre del metodo esta en plural, arriba redacte en singular que es
lo coloquial pero en realidad como sabes se pueden tener varias
conexiones abiertas a la vez, normalmente particionando los modelos
en distintas bases de datos.)

Las soluciones que estamos comentando sencillamente ignoran esa
conexion y abren otra. Entonces pasamos de una conexion persistente a
un conexion por request. Eso es caro en comparacion, pero es
sencillo de escribir y si para tu aplicacion es suficiente mision
cumplida.

Otra aproximacion consiste en mantener un pool de conexiones abiertas
por dispatcher, eso es lo que hace (segun he leido, no he seguido el
codigo) el plugin

http://magicmodels.rubyforge.org/magic_multi_connections/

Pero ya toca/extiende el core. La idea del pool de conexiones como
tal es la solucion canonica. A modo personal el uso mismo del plugin
no acaba de convencerme, pero acaba de salir, y como el tema esta ahi
puede que salgan otras aproximaciones.

Creo que una vez cayo en el radar algo que implementaba el esquema 1
escritura + N lectura mas transparentemente (ese es un caso
particular del problema mas generico de mantener un pool arbitrario y
puede dar lugar a una solucion guapa porque puede asumir mas cosas),
pero no lo encuentro ahora mismo.

– fxn

Si, en vuestro caso, os va a mejorar bastante. Pero no es nuestra
solucion.
Para realizar las comprobaciones utilice los consejos de la siguiente
pagina (por si os viene bien):
http://blog.kovyrin.net/2006/08/28/ruby-performance-results/
Y los resultados, contra un cluster mongrel de 4 instancias, fueron los
siguientes:

  • Con una base de datos: 281 request per second.
  • Con dos bases de datos: 92,4 request per second.

Antes he dicho un 20-30% porque no me acordaba bien, pero como se puede
ver el rendimiento cae a menos de la mitad.
Tambien puede ser que me haya equivocado en algo en las pruebas… o en
la arquitectura.

Un saludo
Roberto M. Oliva

On 4/17/07, Roberto M. Oliva [email protected] wrote:

unico que la logica que nosotros implementamos es discernir el DNS de la

De nuevo, muchas gracias!!
Un saludo
Roberto M. Oliva

Efectivamente, el problema que planteas es cierto, aunque la pérdida
de rendimiento que comentas me parece mucha (no la hemos medido, en
cualquier caso).

La solución, en nuestro caso, es más o menos simple, y la tenemos
medio preparada, pero como no la hemos terminado de probar hemos
preferido no incluirla en el artículo, y poner allí la solución tal
cual la tenemos ahora. Sería simplemente, antes de reestablecer la
conexión, comprobar cuál es la conexión activa y cambiarla sólo si es
necesario. Teniendo en cuenta que en una aplicación como la nuestra
las lecturas son amplíiiiiiiiisima mayoría sobre las escrituras, el
problema practicamente desaparecería (lo contó Nando, más o menos, en
http://www.lacoctelera.com/nando/post/2006/11/30/patrick-lenz-scoop-
). Para vuestro caso, al menos a priori, no parece tan simple =:-(


Sergio Gil Pérez de la Manga
e-mail > [email protected]
blog > http://www.lacoctelera.com/porras

Pon un foro en tu lista y te apedrearán por la espalda.

waooo :stuck_out_tongue:

http://www.romaniconorte.org/es/extras/recomendar.asp?iddoc=929