Recientemente he tenido que enfrentarme al problema de optimizar mi aplicación Rails ( L-exp). El echo es que la carga de una determinada vista me llegaba a tardar más de un minuto. Realmente te quedas bastante frustrado cuando ves que te pasa esto.
Lo primero en pensar es que como Ruby on Rails está desarrollado en Ruby y este es un lenguaje Script. Pues que será lento y que hasta aquí hemos llegado.
Tras profundizar un poco se me ocurren dos caminos a seguir.
El primero analizar la base de datos para detectar problemas de índices. Es decir que se hagan consultas que no utilicen índices y por tanto sean lentas. Para ello utilizo un plugin para Rails llamado Query Analyzer. Este te muestra en el log a que datos acceden y si está utilizando índices. Así puedes detectar consultas complejas e ir optimizando las tablas. Se trata de ir añadiendo índice que contengas los campos por los cuales ejecutamos el query.
Gracias a este proceso detecté varios índices que faltaban y los añadi. Pude comprobar que un query que duraba casi un minuto pasó a durar menos de un 1 segundo.
En paralelo hice la segunda optimización que había leído por alguna parte que era la de utilizar el hash include en las llamadas a la base de datos( find(:all, :include =>”)). La idea es que en vez de hacer muchas consultas, si tiene tablas relacionadas hace una gran consulta trayendo todos los datos de las tablas relacionadas.
Tras acabar de hacer las consultas note una gran mejoría en las listas cortas, pero sin embargo las grandes tardaban mucho.En especial una lista ( Find all the google products and services) que llama a 67 recursos que me tardaba más de un minuto. Entonces…. ¿ donde me he perdido?
El echo es que tras varíos dias dándole vueltas me di cuenta que había cometido un error importante al usar ambos métodos a la vez. Optimizar los índices siempre es bueno ya que es el acceso a la base de datos es acelerado. Este es prioritario y se debe hacer siempre. Mi error fue utilizar el segundo método en consultas que traen muchos datos. Imagino que en estos casos cuando interroga la base de datos y guarda todo en memoria hace que la máquina gaste mucha memoria y CPU siendo poco efectiva para consultas con muchos datos.
Por tanto tan sólo tuve que quitar la optimización de includes y la lista más larga pasó a tardar pocos segundos. Algo impresionante.
Por tanto la moraleja de la historia es: ” Índices, Índices, Índices, ……”
Y el problema en mi caso no era de Rails sino de la base de datos que no la tenía optimizada.
Os adjunto una lista con los plugins que suelo utilizar: Rails plugins
Popularity: 1% [?]
