Optimización, rendimiento y escalabilidad en ActiveRecord

Conferencia Rails 2008

Optimización, rendimiento y
escalabilidad en ActiveRecord

Emili Parreño
www.eparreno.com

Introducción

optimizar != escalar

Optimización, rendimiento y escalabilidad en AR Emili Parreño - www.eparreno.com

Introducción

“La optimización es el proceso de
búsqueda de la mejor manera de realizar un
proceso, con respecto a uno o más
recursos, que pueden ser: tiempo de
ejecución, uso de memoria, uso de CPU...”


Introducción

“La escalabilidad es la propiedad deseable
de un sistema, que indica su habilidad para,
o bien manejar el crecimiento continuo de
trabajo de manera ﬂuida, o bien para estar
preparado para hacerse más grande con un
impacto mínimo en el redimiento.”


Introducción

“El rendimiento es la relación entre los
resultados obtenidos y los recursos
utilizados.”

e = resultados / recursos


Introducción

Optimización => Aumentar el rendimiento

Escalabilidad => Mantener el rendimiento


Reducir el tamaño de las consultas

Consulta ineﬁciente:

def index
@users = User.ﬁnd(:all, :limit => 20)
end

SELECT * FROM users LIMIT 0,10 ORDER BY id desc



Optimización:

def index
@users = User.ﬁnd(:all, :select => “id, name”, :limit => 20)
end



Benchmark (75000 registros):

#1 User.ﬁnd(:all, :limit => 20)

#2 User.ﬁnd(:all, :limit => 20, :select => “id, name, surname”)

user system total real
#1 0.000000 0.000000 0.000000 ( 0.000927)
#2 0.000000 0.000000 0.000000 ( 0.000552)



Benchmark (75000 registros):

#1 User.ﬁnd(:all)

#2 User.ﬁnd(:all, :select => “id, name, surname”)

#1 6.520000 0.350000 6.870000 ( 7.945950)
#2 2.140000 0.040000 2.180000 ( 2.931969)


Contadores
Categorias
- Ruby (1345)
- Rails (2389)
- Testing (345)
- Performance (34)

for cat in @categories
puts “#{cat.name} (#{cat.posts.count})”
end

=> select count(*) from posts where category_id = id

500.000 posts x 4 categorias = 2.000.000 de registros consultados!!


Contadores

Optimización:

class Post < ActiveRecord::Base
belongs_to :category, :counter_cache => true
end

create_table :categories do |t|
t.string :name
...
t.integer :posts_count, :default => 0
t.timestamps
end


Contadores

for cat in @categories
puts “#{cat.name} (#{cat.posts_count})”
end

Evitamos los 2.000.000 de registros recorridos en 4 consultas


Eager Loading


def index
@posts = Post.ﬁnd(:all, :limit => 10)
end

for post in @posts
puts “Titulo:” + post.title
puts “Autor:” + post.user.name
end

=> 1+10 querys


Eager Loading

Optimización:

def index
@posts = Post.ﬁnd(:all, :limit => 10, :include => :user)
end

for post in @posts
end

=> 1+1 querys


Eager Loading

Optimización:

def index
@posts = Post.ﬁnd(:all, :limit => 10, :select => “posts.id,
posts.title”, :include => :user)
end

for post in @posts
end

=> 1+1 querys


Eager Loading

Problema:

Podríamos hacer...

def index
@posts = Post.ﬁnd(:all, :limit => 10, :select => “posts.id,
posts.title, user.id, user.name”, :include => :user)
end

Pero no funciona :(


Eager Loading

Optimización:

def index
@posts = Post.ﬁnd(:all, :limit => 10, :select => quot;posts.title,
users.name AS user_namequot;, :joins => [:user])
end

for post in @posts
puts “Autor:” + post.user_name
end

=> 1 query


Eager Loading


def index
@post = Post.ﬁnd(params[:id])
end

for comment in @post.comments
puts comment.body
puts “Autor:” + comment.user.name
end

=> 1 query para el post
=> 1 query para los comentarios
=> N querys para los usuarios


Eager Loading
Optimización:

def index
@post = Post.ﬁnd(params[:id])
@comments = @post.comments.ﬁnd(:all, :include => :user)
end

for comment in @comments
puts comment.body
puts “Autor:” + comment.user.name
end

=> 1 query para el post
=> 1 query para los comentarios
=> 1 query para los usuarios


Eager Loading
Optimización:

def index
@post = Post.ﬁnd(params[:id],
:include => [:user, :comments])
end

puts “Post:” + @post.body
puts “Autor:” + @post.user.name

for comment in @post.comments
puts “Comentario:” + comment.body
end

=> 3 querys


Tareas en background

Si con lo anterior no es suﬁciente para optimizar una consulta
siempre nos queda el Método de toda la vida:

User.ﬁnd_by_sql(SELECT id, name, surname WHERE user.name = 'Pepe')



Sacar tareas fuera del ciclo del request

- Envío de emails
- Cálculos
- Tareas de mantenimiento
...



Opciones:

- script/runner
- daemon_generator
- BackgrounDRB
- Spawn
- Starling
...


Índices


@users = User.ﬁnd(:all, :conditions => “name = Pepe”)

Recorre toda la tabla


Índices

Evitar consultas que recorran toda la tabla (*)


Índices

Restricciones:

- No utilizar índices en columnas que se actualizan
frecuentemente

- No utilizar índices en columnas con poca variación (p.e.
booleanos)

- No utilizar Índices en tablas pequeñas

- No utilizar índices muy grandes


Índices
Optimización

Añadimos un índice en el campo “name” con una migración

add_index :users, :name

Benchmark 75000 usuarios

@users = User.ﬁnd(:all, :conditions => “name = Pepe”)

#1 0.010000 0.000000 0.010000 ( 0.631635)
#2 0.010000 0.000000 0.010000 ( 0.015232)


Índices

Podemos añadir índices multicolumna

add_index :users, [:name, :city]

No permite índices de más de 1024 bytes

En UTF-8 cada carácter necesita 3 bytes
(256+256)*3 = 1536 bytes
1536 x 500000 = 768 MB

Limitar el tamaño de los campos
t.column :login, :string, :limit => 10, :null => false


Índices

Deﬁnir la longitud del índice

def self.up
execute quot;CREATE INDEX full_name ON users (name(10), surname(10))quot;
end


Índices

“La regla de la izquierda”

Si se utilizan índices multicolumna en las cláusulas WHERE, hay
que incluir siempre de izquierda a derecha las columnas
indexadas
add_index :users, [:name, :surname, :city]

SELECT * from users WHERE city = ʻMadridʼ
SELECT * from users WHERE name = ʻPepeʼ
SELECT * from users WHERE name = ʻPepeʼ AND surname = ʻLopezʼ


Índices y ordenación

Podemos añadir índices multicolumna para ordenar

add_index :users, [:city, :created_at]


MyISAM vs InnoDB
Benchmark 75000 usuarios

User.count
#1 0.000000 0.000000 0.000000 ( 0.663447) (InnoDB)
#2 0.010000 0.000000 0.010000 ( 0.000688) (MyISAM)

User.ﬁnd(:all)
#1 11.040000 0.660000 11.700000 ( 12.585430) (InnoDB)
#2 11.070000 0.670000 11.740000 ( 12.124938) (MyISAM)

User.ﬁnd(:all, :conditions => “name = ‘Pepe’”)
#1 0.010000 0.000000 0.010000 ( 0.015615) (InnoDB)
#2 0.000000 0.000000 0.000000 ( 0.018247) (MyISAM)

MyISAM vs InnoDB

Benchmark 270.000 posts

Post.ﬁnd_by_category_id(14)

#1 0.000000 0.000000 0.000000 ( 0.000865) (InnoDB)
#2 0.000000 0.000000 0.000000 ( 0.001019) (MyISAM)


MyISAM vs InnoDB

Benchmark 270.000 posts

Post.ﬁnd(:all, :conditions => 'body LIKE “Hello”’)

#1 0.000000 0.000000 0.000000 ( 3.471458) (InnoDB)
#2 0.000000 0.000000 0.000000 ( 3.371270) (MyISAM)


Herramientas

Antes de empezar a optimizar: rellenar la base de datos

- populator
- db-populate
- babel
...


Herramientas

Query Reviewer


Herramientas


Herramientas

New Relic


Resumen

• Optimizar es un proceso necesario y contínuo
• Optimizar a medida que desarrollamos o cuando
refactorizamos

• Utilizar herramientas para encontrar “slow
querys”


Resumen

“Constraints force creativity.”
Getting Real - 37 Signals


Emili Parreño - www.eparreno.com


Optimización, rendimiento y escalabilidad en ActiveRecord

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Optimización, rendimiento y escalabilidad en ActiveRecord

Ähnlich wie Optimización, rendimiento y escalabilidad en ActiveRecord (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (11)

Optimización, rendimiento y escalabilidad en ActiveRecord