@GuateonRails => Felicidad.find(:all)

Ruby on Rails: Mejorando el rendimiento de tu aplicación

Posted on: 10 abril 2009


railsEl día de hoy me gustaría dedicar algunas líneas al tema de mejorar el rendimiento de tu aplicación en Ruby on Rails. (Ojo: el sarcasmo va dirigido exlusivamente a pseudo desarrolladores de Ruby on Rails que solo brindan su mál aliento al framework)

El temas sale directamente de la controversia que surge a partir de que Twitter anunciara que cambiará su sistema de mensajería de Ruby a Scala. Las razones de los señores de Twitter son bastante razonables, sin embargo esto ha generado un gran número de posts sobre “ya ven se los dije Ruby no sirve”, “no usen Ruby es la cosa mas lenta que hay”, “Rails no se compara con la velocidad de PHP”, y otro montón de tonterías. Para que no se asusten y para no me picarme el hígado mas de la cuenta les dejó más abajo la presentación de los señores de Twitter del porque de su decisión para migrar de Ruby a Scala.

Muy bien, ahora pasando a modo pro-activo, les voy a compartir un par de consejos para que no se conviertan en uno de esos “desarrolladores de Ruby on Rails”, que comentan decepcionados el como Rails no tiene un buen rendimiento y mejor se pasan a algo más “eficiente”.

He aquí tres puntos que considero de suma importancia para cualquier desarrollador que desee mejorar el rendimiento de sus aplicaciones o planificar adecuadamente una nueva aplicación.

1. Pobre diseño o elección de la base de datos

Voy a sonar de lo mas pedante, pero…. por favor antes de empezar a escribir scaffold, scaffold, scaffold les recomiendo tomarse 5 minutos (si pueden que sean 6) y pensar que están haciendo y por qué lo están haciendo. Nada mejora el rendimiento de una aplicación de Rails como un buen diseño de base de datos.

Si nunca lo han hecho les recomiendo leer algún libro sobre el tema o tomar algún curso o algo… porque no creerán las aplicaciones con las que me he encontrado en el mercado, las cuales me han dado mas de una razón para exclamar alguna grosería en el nombre de todo lo que es santo, cuando veo la estructura sobre la cual están corriendo.

Recuerden el objetivo de cualquier framework es el de brindar una forma de trabajo simplificada bajo la premisa de que existen tareas comunes que se repiten constante y de que la persona que está sentada frente al teclado sabe lo que está haciendo. Rails no es una muleta para aquellas personas que desean convertirse en “desarrolladores web” en diez minutos o menos. Rails está diseñado para “desarrolladores web” que desean incrementar su productividad y deciden usar este framework en particular para hacerlo.

2. Indices

Por alguna razón los “desarrolladores” de Rails, tienen la extraña idea de que esos viejos amigos de la infancia no tienen nada que ver con el ciclo de vida de las aplicaciones de RoR. Pero ¡oh sorpresa!, en el 90% de los casos un simple indice puede reducir el tiempo de respuesta de su aplicaciones en mas de un 100%.  Los índices a sus campos siguen teniendo la misma preminencia para las aplicaciones en RoR como para cualquier otro tipo de desarrollo. Si no los incluyes o no sabes como hacerlos bien tu aplicación pagará las consecuencias. El por qué y el como generarlos es asunto tanto de la lógica de tu aplicación como del manejador de datos que hayas elegido.

Para aquellos que les guste desarrollar bajo MySQL les sugiero que se familiarizen con el comando DESCRIBE el cual les permitirá determinar el ciclo de ejecución de sus queries.

Y para los que no sabían que RoR generá a su mas bajo nivel simples queries de sql (¡Oh Maravilla!) les suplico que se den una vuelta por la consola que está corriendo su servicio o mejor aún que le den una visita al archivo de logs.  ¿Rails tiene un log…? Si amigo mio RoR guarda (según su ambiente de trabajo) el resultado de sus operaciones incluyendo (en el ambiente de desarrollo) los queries que se han ejecutado contra la base de datos.

Los archivos de logs puden ser localizados el directorio (extrañamente llamado) miaplicacion/logs.

Tip para los usuarios Linux:

Los archivos de logs pueden ser limpiados por medio de la instrucción

$ rake log:clear (esto tambien aplica para otros SO)

y pueden visualizarse de una manera simple con:

$ cat log/development.log  | less -R

Y si desean ser un poco mas minuciosos con su trabajo,  les recomiento encarecidamente que instalen el plugin para MySql,  Query Analyzer. El cual modificará la salida de los archivos de log para incluir el resultado del comando DESCRIBE por cada query que se ejecute. La combinación de estos comandos y el entender que es lo que los logs muestran es tal vez la herramienta más poderosa para mejorar el rendimiento de una aplicación de Rails.

3. Poco conocimiento sobre el manejo del modelo de objetos de datos

La forma en que Rails por medio de la clase ActiveRecord obtiene el acceso a los manejadores de base de datos en simplemente una delicia en cuanto a la claridad y calidad de código que nos permite escribir, y en mi opinión Active Record es la pieza mas importante del asernal de RoR.

Nota: Si desean entender mejor su funcionamiento (por cierto ActiveRecord puede ser usado por cualquier aplicación escrita en Ruby) les recomiendo leer el libro  Pro Active Record : Databases with Ruby on Rails.

Ahora con lo concerniente a rendimiento RoR nos permite hacer cosas como:

personas = Persona.find(:all, :conditions=>condiciones_para_encontrar_personas)

lo cual ejecutará el query

select * from personas where "condiciones para encontrar personas"

Si nosotros deseásemos obtener la información de los paises de los  amigos de esta persona podríamos escribir el siguiente código:

persona = Persona.find(:all, :conditions=>condiciones_para_encontrar_persona)

@pais_de_amigos = persona.amigos.collect {|amigo| amigo.pais.nombre }

ahora eso funcionara sin problema, pero generará un query para obtener los amigos y un query por cada amigo para poder obtener la información del país. Ahora estó talvez no se note al principio, pero piensen en una aplicación como Twitter y la cantidad de amigos que puedan seguir a una persona, y verán que ese código es super ineficiente.

La solución de este problema cabe simplemente en conocer como funciona el módelo de objetos de RoR y poder hacer uso de él. El código anterior puede ser mejorado con solo usar eager associations, es decir traer toda la información necesaria con un solo query, tal y como se ha hecho por generaciones en cualquier otro ambiente de trabajo. Al agregar el parámetro :include a nuestra metodo find nos es posible obtener la información necesaria de nuestra tablas asociadas en un solo query. El anterior código sería rectificado de la siguiente manera:

persona = Persona.find(:all, :conditions=>condiciones_para_encontrar_persona, :include => :pais)

@pais_de_amigos = persona.amigos.collect {|amigo| amigo.pais.nombre }

lo cual generaría

select * from personas inner join paises on personas.pais_id = pais.id where condiciones_para_encontrar_persona

Como ven nada del otro mundo… simplemente saber que estamos haciendo nos puede brindar grandes satisfacciones al trabajar bajo Ruby on Rails. Así que ya saben, a estudiar diseño de base de datos y darle una miradita a la clase Active Record. Nada les cuesta y verán como sus aplicaciones se transforman de “esa cosa en Rails” a “la aplicación con la que quiero pasar el resto de mis días mientras me hace millonario”.

Saludos y Exitos en su lucha contra el mal!!

5 comentarios to "Ruby on Rails: Mejorando el rendimiento de tu aplicación"

Quisiera saber cuales son las aplicacionesTRANSACCIONALES que has hecho en Ruby??, para que hables con tanta propiedad, si me dices que tienes un sistema que haga transacciones grandes para una empresa real y que este en produccion sin que un cambio genere el paro del sistema, podre decir que tienes razon, pero si lo que haces con Ruby solo son Blogs o carritos de compras (que es el ejemplo que esta en la mayoria de libros), no me convenceras ya que Ruby solo es bueno para eso, para aplicaciones de una utilidad mas enterprise no funciona y que es lento creo que no es justo la verdad es LENTISIIIIIIIIIIIIMO

Mi respuesta a tu correo. Y para tu tranquilidad, nunca he desarrollado un carrito de compras.😉

Ha ok que bien eso responde a una parte de mi pregunta, la otra pregunta es cuales aplicaciones si ha hecho?, así quedare mas tranquila😉

Mi trabajo siempre ha sido aplicaciones empresariales empezando con grandes bases de datos gubernamentales con gran concurrencia y enlaces y reportes en tiempo real de ejecucion de presupuestos y avance de proyectos hacia entidades bancarias o entidades intermediarias. Siguiendo con desarrollo de ERP’s y actualmente trabajando para clientes en estados unidos que brindan servicio 24×7 a empresas como la marina de los estados unidos, texaco, shell etc.

Estoy de acuerdo contigo, la sencillez de Rails lo hace un arma muy peligrosa cuando se desconoce lo que sucede tras su capa de abstración.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Sigueme…

Categorías

Cosas que salen de mi cabeza

A %d blogueros les gusta esto: