Pregunta ¿Los sitios de Ruby on Rails tienen problemas de rendimiento? [cerrado]


¿El sitio de Ruby on Rails suele ser más lento que los sitios de java o .net? (Esto supone que los desarrolladores no están abusando de la tecnología).

Muchos sitios de Ruby que he visto tienen problemas de rendimiento.


22


origen


Respuestas:


Sí, los sitios de Ruby on Rails tienen problemas de rendimiento, al igual que cualquier otro sitio. Y al igual que en cualquier otro sitio, ese rendimiento casi siempre está enraizado en las decisiones arquitectónicas, no en el lenguaje o el marco.

Hubo una bonita presentación hace un par de años por Joyent (¿podría haber sido RailsConf 2007?), Que mostró en una diapositiva todos los servidores que se ejecutan en una sola instancia de su plataforma Rails. Alrededor de 40 procesos. Solo uno de esos procesos fue el intérprete de Ruby, todo lo demás era cosas como la resolución DNS, el servidor web, el servidor de bases de datos, MTA, memcached, cola de mensajes, proxy inverso, balanceador de carga, etc. Cada uno de ellos puede arruinar su rendimiento . Eso es un 97.5% de posibilidades de que tus problemas de rendimiento no tengan nada que ver con Rails o Ruby.

Hay algunos E-Mails realmente agradables en las listas de correo JRuby, y también algunos tweets y publicaciones en blogs de personas que reescribieron sus aplicaciones web Java en Ruby y obtuvieron una mejora del 10% en el rendimiento.

Un buen ejemplo es Twitter. Twitter es uno de los sitios más grandes de Ruby on Rails en el mundo. También es uno con un patrón de uso muy inusual que dará alguna marco que está diseñado para aplicaciones web "normales", una tuerca difícil de romper.

Ahora, podrías pensar, ¿por qué elegí Gorjeo de todas las cosas como un ejemplo de rendimiento y escalabilidad, cuando claramente es la exacta opuesto que son conocidos por? Bueno, ese es exactamente el punto: han tenido una tonelada de escala, rendimiento y problemas de fiabilidad. Y no un solo uno de esos tenían algo que ver con Rails o Ruby. De hecho, Rails y Ruby eran prácticamente las únicas piezas en su stack que hicieron no tiene problemas con.

Tuvieron problemas con un crecimiento inesperado. No importa qué idioma o marco utiliza: si los usuarios inician sesión más rápido de lo que puede comprar nuevos servidores, no hay nada que pueda hacer.

Tenían problemas con el rendimiento y la escalabilidad de MySQL. Una vez más, MySQL no tiene nada que ver con Rails o Ruby. De hecho, MySQL está escrito en C, así que si De Verdad absolutamente debe Haga una conclusión ridícula sobre un lenguaje de programación, basado únicamente en un solo incidente, entonces sería esto: C es lento. Si quieres rendimiento, mantente alejado de C.

(En este caso particular, en una entrevista, en realidad hizo culpan a Rails: dijeron que debido a que Rails solo admitía una única conexión a una única base de datos, su instancia de MySQL simplemente se sobrecargó. A las pocas horas de haberse publicado la entrevista, dos desarrolladores de Rails independientes uno del otro lanzaron complementos de Rails para implementar conexiones múltiples. La lección es: solo las soluciones del 80% están en el núcleo. Twitter claramente no está en el 80%. La API de complemento está ahí por una razón).

Tuvieron problemas con el rendimiento y la escalabilidad del sistema en general. Resultó que, para sacar el producto rápidamente, no implementaron ningún tipo de almacenamiento en caché. Incluso la página de inicio "estática" de Twitter se generó de manera completamente dinámica para cada solicitud. De nuevo, esto no tiene nada que ver con Rails o Ruby. Puedes traer alguna sitio abajo al desactivar sus cachés, te lo garantizo.

Llegan a algunos muy malos problemas de escalabilidad (y los problemas de MySQL mencionados anteriormente están relacionados con eso) que fueron causados ​​simplemente por el hecho de que las personas usaban el sitio de una manera no anticipada por los desarrolladores. Todo el mundo sabe que Twitter es una plataforma de micro mensajería. Bueno, a excepción de los fundadores de Twitter. Tenían esta idea brillante para un sistema de administración de contenido micro.

Y entonces, ellos hizo construir un micro-CMS. Y, por supuesto, la pieza central de un sistema de gestión de contenido es un repositorio de contenido, IOW una base de datos. Sin embargo, los usuarios usaron Twitter como una plataforma de micro mensajería. Y la pieza central de una plataforma de mensajería es una cola de mensajes.

Como resultado, MySQL se estaba utilizando como una cola de mensajes. No hay dos cosas más allá de una base de datos (especialmente una base de datos SQL) y una cola de mensajes. Los dos tienen requisitos y limitaciones casi exactamente opuestos.

Y, por supuesto, toda la arquitectura fue construida alrededor ese repositorio de contenido que ahora se abusaba como una cola de mensajes.

En respuesta a eso, los desarrolladores de Twitter escribieron su propia cola de mensajes en Ruby, lo que ayudó mucho al rendimiento y la escalabilidad. Pero no suficiente. Entonces, escribieron otra cola de mensajes, esta vez en Scala.

Es esta única reescritura de la que es totalmente responsable, estimaría, al menos el 70% de todo el FUD de Rails. Pero, no sé ustedes: cuando escribo algo que no tengo ni idea de cómo escribirlo, y luego escribo exactamente lo mismo por segunda vez, cuando en realidad hacer sé qué diablos estoy haciendo ... el segundo siempre es mejor que el primero. Y sospecho que este es el caso aquí, también.

En varias entrevistas, los desarrolladores de Twitter han señalado que Ruby on Rails no era responsable de sus problemas de escalado. Por el contrario, solo la capacidad de mantenimiento de Ruby hizo posible realizar cambios arquitectónicos a gran escala en fijar sus problemas de escala

Para abreviar: en la actualidad, Twitter está usando Ruby on Rails para lo que estaba destinado a ser utilizado: para una aplicación web. Y usan una base de datos para almacenar datos y no como una cola de mensajes. Y usan una cola de mensajes propiamente dicha. La cola de mensajes y algunas otras cosas de back-end están escritas en Scala. La interfaz está escrita en Ruby on Rails. Algunas cosas están escritas en C.

Y todo es color de rosa

los real La moraleja de la historia aquí es que puedes sustituir casi alguna una gran aplicación web, cualquier lenguaje, cualquier marco en la historia anterior y aún sería cierto. MySpace es uno de los sitios web más lentos y poco confiables que conozco, y es un sitio .NET. GitHub es uno de los sitios web más rápidos que conozco, siendo la plataforma de alojamiento más grande (tiene más de un millón de repositorios después de 2 años, es más que SourceForge y Google Code combinados) y está escrito en Ruby on Rails para la interfaz, Sinatra para el servicio web, Ruby para la interfaz Git y la infraestructura Git, Erlang para la infraestructura de federación y nube y Node.JS para el servidor de descarga.


83



Aquí hay un comienzo

Escalar ROR

Por qué los rieles pueden correr lentamente

Comparación del rendimiento del marco

Pregunta relacionada con SO

Artículo de interés relacionado Twitter abandona ROR es viejo, lo sé, pero realmente no sabía que lol

Respuesta corta
Podría ser seguro.
Podría ser más probable que algunos otros idiomas.
Depende de la aplicación, el programador y la arquitectura.



6



Como lo veo, RoR es solo un poco más lento. Al menos más lento que .Net, porque el rubí es un lenguaje interpretado.

Pero, en general, depende de la calidad de los desarrolladores. La aplicación RoR que utiliza buen almacenamiento en caché funciona n veces más rápido que la aplicación .net / java que carga la mitad de la base de datos en la memoria y envía muchas solicitudes de bases de datos causadas por select n+1.


2



sí, es más lento, pero en producción probablemente solo le hará daño una vez que su carga "excede cierto punto" ("x solicitudes / seg") y la mayoría de los sitios nunca ven más carga que eso.


0



Preguntas populares