ORM com ActiveRecord no Rails facilita o trabalho do desenvolvedor, mas quando o sistema cresce o uso inadequado do poder de ActiveRecord pode trazer problemas como baixa performance. Coisas como mapeamentos equivocados, queries N+1, navegação entre Objetos, podem gerar excesso de queries e dificultar a execução, evolução e manutenção do sistema. Venha ver na apresentação técnicas que podemos aplicar como: uso de scopes, includes, queries customizadas com mapeamentos alternativos, testes automatizados validando número de queries geradas, monitoramento com NewRelic, dentre outras que garantem maior performance sem abrir mão do poder que ORM com ActiveRecord dá aos desenvolvedores.

1. Maior performance no seu sistema
com o uso adequado de
ORM em Rails

3. Vamos usar outra linguagem
Ruby é lento
Vamos fragmentar o sistema
Precisamos reescrever do zero

4. Será que o problema é a
linguagem ou o framework?
Ou não estamos usando
eles de forma adequada?

5. ORM
EM
RAILS

6. Object
Relational
Mapping

7. Rails nos oferece
Active
Record
Ele é um Pattern!
Martin Fowler

8. Order
Customer
Order Items
Product
Shipping Company
Delivery

9. >Order.create(customer:...)
>Order.find(1).customer.name
>Order.find_by(customer:1).order_items.count
>Order.all
class Customer < ApplicationRecord
end
class Delivery < ApplicationRecord
belongs_to :shipping_company
belongs_to :ordem_item
end
class Order < ApplicationRecord
belongs_to :customer
has_many :order_items
end
class OrderItem < ApplicationRecord
belongs_to :order
belongs_to :product
has_one :delivery
end
class Product < ApplicationRecord
end
class ShippingCompany < ApplicationRecord
end
Order Load (1.0ms) SELECT "orders".* FROM
"orders" LIMIT $1 [["LIMIT", 11]]
=> #<ActiveRecord::Relation [#<Order id: 1,
customer_id: 2, status: "ENTREGUE", ...]>

10. <table>
<thead>
<tr>
<th>Id</th>
<th>Status</th>
</tr>
</thead>
<tbody>
<% @orders.each do |order| %>
<tr>
<td><%= order.id %></td>
<td><%= order.status %></td>
</tr>
<% end %>
</tbody>
</table>

11. <table>
<thead>
<tr>
<th>Customer</th>
<th>Status</th>
</tr>
</thead>
<tbody>
<% @orders.each do |order| %>
<tr>
<td><%= order.customer.name %></td>
<td><%= order.status %></td>
</tr>
<% end %>
</tbody>
</table>

12. Para 10.000 orders, até 10.001 consultas ao banco
(Queries N+1)
def index
@orders = Order.all
end
def index
@orders = Order.all.includes(:customer)
end
2 consultas ao banco de dados
def index
@orders = Order.all.joins(:customer).includes(:customer)
end
1 consulta ao banco de dados

13. Default
16171ms
9408ms
9574ms
9783ms
17361ms
19387ms
13.6s
Qual melhor estratégia?
Include
1490ms
1440ms
1844ms
1581ms
1555ms
1969ms
1.6s
Join + Include
2044ms
2168ms
1536ms
1903ms
1978ms
1668ms
1.8s
+ db index
1579ms
1653ms
1575ms
1556ms
1613ms
1564ms
1.5s

14. Como coletar
essas métricas?

15. Uso do log do rails server

17. Application
Performance
Management (APM)

19. 15ms
1ms
https://github.com/newrelic/rpm

21. Porque esses
problemas ocorrem ?

22. SOLUÇÃO CRESCE !
● FEATURES COMPLEXAS
O TIME CRESCE !!!
● MAPEAMENTOS EQUIVOCADOS
● MAU USO DE NAVEGAÇÃO
ENTRE OBJETOS
● MODELAGEM CONFUSA

23. Como evitar
esses problemas ?

24. Bullet
https://github.com/flyerhzm/bullet

25. DB Query Matchers
https://github.com/brigade/db-query-matchers
teste A
teste B
teste C
teste D
teste E
teste F
teste G
teste H
teste I
teste J
teste K
teste L

26. require 'rails_helper'
feature 'orders index' do
scenario 'list all' do
expect { visit('/orders') }.to make_database_queries(count: 3)
end
scenario 'list all' do
expect { visit('/orders_include') }.to make_database_queries(count: 2)
end
scenario 'list all' do
expect { visit('/orders_join') }.to make_database_queries(count: 1)
end
end

28. expect { }.to_not make_database_queries(matching: /UPDATE/)
expect { }.to_not make_database_queries
expect { }.to make_database_queries(count: 1)
expect { }.to make_database_queries(count: 0..3)
expect { }.to_not make_database_queries(manipulative: true)
(INSERT, UPDATE, DELETE)

29. Boas
Práticas

30. Uso de Scope
def index_with_join
@orders = Order.all.joins(:customer).includes(:customer)
end
Controller
class Order < ApplicationRecord
belongs_to :customer
has_many :order_items
scope :all_with_customer, -> {Order.all.joins(:customer).includes(:customer)}
end
Model
def index_with_join
@orders = Order.all_with_customer
end
Controller

31. Evite...
scope :all_with_customer, -> {
Order.all.includes(:customer).order(:status)}
Ordenação
default_scope :active, -> {Customer.where(active:true)}Default
scope :closed, -> {Order.where(status:‘closed’)
.where(‘total_amount >= ?’, 10.0)}
Itens
Implícitos
scope :closed, -> do
find_by_sql <<-SQL
select * from orders where status = ‘closed’
SQL
end
SQL puro

32. Queries customizadas com
Mapeamento Alternativos
class SummaryOrder < ApplicationRecord
self.table_name = "orders"
scope :all_summarized, -> {
select('orders.id')
.select('customers.name')
.select('orders.status')
.select('count(order_items.id) as items_quantity')
.joins('left join customers on orders.customer_id = customers.id')
.joins('right join order_items on order_items.order_id = orders.id')
.group('orders.id, customers.name, orders.status')
}
end

33. ...
<tr>
<th>Customer</th>
<th>Status</th>
<th>Quantity of Items</th>
</tr>
...
<% @summary_orders.each do |summary_order| %>
<tr>
<td><%= summary_order.name %></td>
<td><%= summary_order.status %></td>
<td><%= summary_order.items_quantity %></td>
</tr>
<% end %>
...
class SummaryOrder
attr_accessor :id,
:name,
:status,
:items_quantity
end

35. count, length ou size ?
count
length

36. size

37. OO ou SQL?
Dê preferência ao uso de OO!
OO não pode sacrificar performance
ORM é um facilitador, conhecer SQL e banco de dados
ainda é importante
Não abra mão do poder do banco de dados

38. > SummaryOrder.all_summarized.explain
HashAggregate (cost=871.09..971.09 rows=10000 width=57)
Group Key: orders.id, customers.name
-> Hash Left Join (cost=349.70..796.09 rows=10000 width=57)
Hash Cond: (orders.customer_id = customers.id)
-> Hash Left Join (cost=319.00..639.24 rows=10000 width=33)
Hash Cond: (order_items.order_id = orders.id)
-> Seq Scan on order_items (cost=0.00..194.00 rows=10000 width=16)
-> Hash (cost=194.00..194.00 rows=10000 width=25)
-> Seq Scan on orders (cost=0.00..194.00 rows=10000 width=25)
-> Hash (cost=19.20..19.20 rows=920 width=40)
-> Seq Scan on customers (cost=0.00..19.20 rows=920 width=40)
Explain

39. Vimos resumidamente...
Includes
Joins Scopes
Mapeamentos Alternativos
New Relic Bullet
DB Query Matchers
Queries N+1
Count, Length, Size
Explain

40. Isso resolve todos
os problemas ?
provavelmente
não!
Talvez ainda seja
necessário...
● Reescrever
● Fragmentar
● Ou até usar outra
linguagem

41. Faça pelos
motivos adequados!

42. Verifique se o
problema de performance
não é mal uso de ORM

43. Obrigado !
Isaac Felisberto de Souza
isaacsouza@gmail.com
linkedin.com/in/isaacfsouza
Dúvidas ?