Casos de otimização em aplicações Ruby on Rails

Transcript

1. Optimisation Techniques for Ruby on Rails Applications TÉCNICAS DE OTIMIZAÇÃO PARA APLICAÇÕES RUBY ON RAILS Gabriel Sobrinho
2. • Caching • Active Record • Lightning • Database View • Otimização de SQL • Fast Detect • Parse e dump de JSON • Parse e dump de XML • Gargabe Collector • Background Job • Assets • Planilhas • PDFs • CPU Bound Agenda
3. GABRIEL SOBRINHO gabrielsobrinho.com github.com/sobrinho twitter.com/sobrinho speakerdeck.com/sobrinho
4. We are hiring! become@codeminer42.com
5. Caching
6. There are only two hard things in Computer Science: cache invalidation and naming things. — Phil Karlton Caching
7. • Rails.cache • View Caching • HTTP Caching Caching
8. Rails.cache.fetch(cache_key) do # some expensive calculation end Rails.cache
9. class Cep def self.find(cep) cache_key = "cep/#{cep}" options = { expires_in: 7.days } Rails.cache.fetch(cache_key, options) do response = HTTPI.get(...) JSON.parse(response.body) end end end Rails.cache
10. DICA • Configure um banco de caching como o memcached para ambientes distribuídos • Use somente se o tempo de processamento for maior que o tempo médio de rede do banco de caching • Cuidado com o dog-pile effect
12. <% cache cache_key do %> <%# some expensive rendering %> <% end %> View Caching
13. <% cache project do %> <%= render project.comments %> <% end %> View Caching
14. DICA • Use somente se a renderização for complexa (lenta) • Tempo médio de renderização deve ser maior que o tempo médio de rede • Russian Doll Caching
15. def show @product = Product.find(params[:id]) fresh_when @product end HTTP Caching
16. def show @product = Product.find(params[:id]) if stale?(@product) @statistics = build_statistics(@product) respond_to do |format| ... end end end HTTP Caching
17. DICA • Use somente se a resposta da requisição puder ser cacheada por completo • Existem técnicas para contornar essa limitação usando JavaScript • Procure sobre rack-etag e rack-cache
18. Referências http://blog.plataformatec.com.br/2009/09/como-evitar-dog-pile-effect-no-rails/ https://robots.thoughtbot.com/introduction-to-conditional-http-caching-with-rails https://robots.thoughtbot.com/take-control-of-your-http-caching-in-rails https://devcenter.heroku.com/articles/http-caching-ruby-rails
19. Active Record
20. products = Product.all products.each do |product| puts product.category.name end N+1
21. products = Product .includes(:category) .all products.each do |product| puts product.category.name end N+1
22. DICA • Use a gem bullet para identificar N+1 e eager loads não utilizados • Ferramentas como NewRelic e Skylight monitoram esses problemas em produção • A biblioteca goldiloader resolve a maioria sozinho
23. products = Product.all products.each do |product| puts product.comments.count end Counter Cache
24. class Product < ActiveRecord::Base has_many :comments, counter_cache: true end Counter Cache
25. DICA • Se o ambiente for distribuído a contagem nem sempre será perfeita (non thread-safe) • Se a contagem for importante, use trigger no banco de dados ou cache da view
26. Person.limit(100_000).to_a # Person Load (868.6ms) SELECT "pessoas".* FROM "pessoas" LIMIT 100000 Tempo de alocação
27. require 'benchmark' puts Benchmark.measure { Person.limit(100_000).to_a } # 5.130000 0.030000 5.160000 ( 5.807508) Tempo de alocação
28. DICA • Não confie nos logs de tempo da instrumentação do rails • Evite consultas que retornam milhares de resultados com o Active Record
30. • Técnica sugerida pela Brainspec • Ao invés de alocar objetos do active record, aloca apenas hashes puros • Ganho de pelo menos 30% no tempo de alocação Lightning
31. Benchmark.benchmark do |bm| bm.report("to_a") do Person.limit(100_000).to_a end bm.report("lightning") do Person.limit(100_000).lightning end end Lightning
32. def self.lightning connection.select_all(all.to_sql).each do |attrs| attrs["id"] = attrs["id"].to_i end end Lightning
33. DICA • Somente faz sentido se você não precisar da estrutura do active record • Compare o tempo de alocação, a tendência é o rails e ruby se tornarem mais rápidos com o passar do tempo
34. Referências https://github.com/flyerhzm/bullet https://www.sitepoint.com/silver-bullet-n1-problem/ http://railscasts.com/episodes/23-counter-cache-column https://tenderlovemaking.com/2014/02/19/adequaterecord-pro-like-activerecord.html http://brainspec.com/blog/2012/09/28/lightning-json-in-rails/ https://hackernoon.com/speed-up-allocating-activerecord-objects-86c7ced839a5#. 3650tvbe5 https://www.skylight.io
35. • Database View • Materialised View Database View
36. product = Product.find(...) product.owner product.category product.comments Database View
37. select * from products where id = ?; select * from owners where id = ?; select * from categories where id = ?; select * from comments where product_id = ?; Database View
38. create view products_report as select p.name AS product_name, o.name AS owner_name, c.name AS category_name, array_agg(cm.author) AS comment_authors, array_agg(cm.body) AS comment_bodies from products p join owners o on o.id = p.owner_id join categories c on c.id = p.category_id join comments ct on ct.product_id = p.id group by 1, 2, 3 Database View
39. select * from products_report; select * from products_report where product_name = 'Ruby'; Database View
40. class ProductsReport < ApplicationRecord end Database View
41. class ProductsReport < DatabaseView end Database View
42. DICA • Reduz o tempo de rede consideravelmente • Recursos específicos do banco podem tornar difícil a migração para outra solução mas ninguém usa ORM para isso * • Use a gem scenic da Thoughtbot para facilitar o versionamento das views nas migrations
43. create view products_report as select p.name AS product_name, o.name AS owner_name, c.name AS category_name, array_agg(cm.author) AS comment_authors, array_agg(cm.body) AS comment_bodies from products p join owners o on o.id = p.owner_id join categories c on c.id = p.category_id join comments ct on ct.product_id = p.id group by 1, 2, 3 Materialised View
44. create materialized view products_report as select p.name AS product_name, o.name AS owner_name, c.name AS category_name, array_agg(cm.author) AS comment_authors, array_agg(cm.body) AS comment_bodies from products p join owners o on o.id = p.owner_id join categories c on c.id = p.category_id join comments ct on ct.product_id = p.id group by 1, 2, 3 Materialised View
45. create index pr_name on products_report(product_name); create index pr_owner_name on products_report(owner_name); Materialised View
46. -- locks the view refresh materialized view products_report; -- does not lock the view refresh materialized view concurrently products_report; Materialised View
47. class ProductsReport < DatabaseView def self.refresh connection.execute <<-SQL REFRESH MATERIALIZED VIEW products_report SQL end end Materialised View
48. class ProductsReport < MaterializedDatabaseView end Materialised View
49. DICA • Recomputar a view pode ser feito por triggers no banco ou workers na aplicação • Índices podem otimizar ainda mais as consultas na materialized view • REFRESH sempre recomputa todos os registros, mesmo os sem modificação
50. Referências https://www.postgresql.org/docs/9.5/static/sql-refreshmaterializedview.html https://blog.pivotal.io/labs/labs/database-views-performance-rails https://www.sitepoint.com/speed-up-with-materialized-views-on-postgresql-and-rails/ https://robots.thoughtbot.com/announcing-scenic--versioned-database-views-for-rails
51. explain analyze select * from people where name = 'GABRIEL CAMPOS SOBRINHO'; EXPLAIN ANALYZE
52. Seq Scan on people (cost=0.00..10174.39 rows=1 width=182) (actual time=13.330..48.007 rows=1 loops=1) Filter: ((name)::text = 'GABRIEL CAMPOS SOBRINHO'::text) Rows Removed by Filter: 303630 Planning time: 0.114 ms Execution time: 48.077 ms EXPLAIN ANALYZE
53. create index people_name on people(name); EXPLAIN ANALYZE
54. Index Scan using people_name on pessoas (cost=0.42..8.44 rows=1 width=182) (actual time=0.002..0.002 rows=1 loops=1) Index Cond: ((nome)::text = 'GABRIEL CAMPOS SOBRINHO'::text) Planning time: 0.261 ms Execution time: 0.021 ms EXPLAIN ANALYZE
56. DICA • Todo banco possui uma forma de consultar o que está acontecendo na consulta • Estude a documentação do seu banco de dados para entender como otimizar • Se precisar de LIKE no Postgres, use o pg_trgm para indexar
57. Referências https://www.postgresql.org/docs/current/static/sql-explain.html http://stackoverflow.com/questions/12915209/how-to-understand-an-explain-analyze
58. students.each do |student| disciplines.each do |discipline| student_note = Note.find_by( student_id: student.id, discipline_id: discipline.id ) end end Fast Detect
59. notes = Note.where(...) students.each do |student| disciplines.each do |discipline| student_note = notes.select do |note| note.student_id == student.id && note.discipline_id = discipline.id end end end Fast Detect
60. data = Hash.new { |h, k| h[k] = {} } notes.each do |note| data[note.student_id][note.discipline_id] = note end Fast Detect
61. students.each do |student| student_note = data[student.id][discipline.id] end Fast Detect
62. DICA • Use para otimizar acessos repetitivos em longas coleções • Garanta que esse realmente seja o hotspot, na maioria das vezes o tempo de pesquisa não é significativo
63. Referências https://blog.engineyard.com/2015/five-ruby-methods-you-should-be-using
64. Benchmark.benchmark do |bm| bm.report 'to_json' do JSON.parse(JSON.dump(x)) end bm.report 'yajl' do Yajl::Parser.parse(Yajl::Encoder.encode(x)) end bm.report 'oj' do Oj.load(Oj.dump(x)) end end JSON
65. DICA • Oj em média faz o mesmo processamento na metade do tempo • Oj possui uma implementação alternativa que pode ser até 20x mais rápida • Compatível apenas com MRI e Rubinius
66. Referências https://github.com/ohler55/oj https://github.com/brianmario/yajl-ruby
67. Benchmark.benchmark do |bm| bm.report 'nokogiri' do Nokogiri::XML(xml) end bm.report 'ox' do Ox.parse(xml) end bm.report 'libxml' do LibXML::XML::Document.string(xml) end end XML
68. DICA • libxml em média faz o mesmo processamento na metade do tempo • libxml possui um preocupante histórico de vunerabilidades (nokogiri usa libxml) • ox se vende como mais seguro por não depender do libxml
69. Referências http://www.nokogiri.org http://xml4r.github.io/libxml-ruby/ https://github.com/ohler55/ox
70. RUBY_GC_HEAP_INIT_SLOTS RUBY_GC_HEAP_FREE_SLOTS RUBY_GC_HEAP_GROWTH_FACTOR RUBY_GC_HEAP_GROWTH_MAX_SLOTS RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR RUBY_GC_MALLOC_LIMIT RUBY_GC_MALLOC_LIMIT_MAX RUBY_GC_MALLOC_LIMIT_GROWTH_FACTOR RUBY_GC_OLDMALLOC_LIMIT RUBY_GC_OLDMALLOC_LIMIT_MAX RUBY_GC_OLDMALLOC_LIMIT_GROWTH_FACTOR Garbage Collector
71. DICA • tunemygc.com monitora e tuna seu GC de acordo com a sua aplicação • Tenha certeza que o GC está sendo um problema na sua aplicação
72. Referências https://helabs.com/artigos/2014/12/19/ruby-gc-tuning-parameters/ http://collectiveidea.com/blog/archives/2015/02/19/optimizing-rails-for-memory-usage- part-2-tuning-the-gc/
73. DICAS RÁPIDAS
74. • Não otimiza a aplicação mas libera o application server para continuar atendendo requisições • Cuidado com gargalos no banco de dados • Sidekiq é a opção mais utilizada mas não é a mais robusta Background Job
75. • Utilize o asset pipeline ou webpack • Compacte os assets com minificação e gzip • CDNs podem reduzir o tempo de rede consideravelmente Assets
76. • Prefira CSV ao invés de XLSX • Se for necessário criar fórmulas e gráficos, utilize o axls • Se a planilha for complexa, prefira gerar em background job Planilhas
77. • wkhtmltopdf consome muito recurso (processamento e memória) • prawn e prawn-table costuma ser a melhor opção • Alternativas incluem usar o jRuby com bibliotecas java ou integração com o iReport + Jasper Reports PDF
78. • Ruby nem sempre é a melhor opção para CPU Bound • Procure sobre Crystal, Rust, C e similares para integrar usando a gem FFI CPU Bound
79. RESUMO • Sempre faça profiling para ter certeza sobre o que está lento na sua aplicação • Seu problema de performance provavelmente já foi resolvido por alguém
80. RESUMO • Não tenha medo de usar os recursos do banco de dados, é o principal ponto de otimização na maioria das aplicações • Compartilhe conhecimento sempre que criar ou aprender uma nova técnica
81. Thanks!
82. Questions?
83. Thanks!
84. We are hiring! become@codeminer42.com