Como aumentar o desempenho do Rails

Rubi Primeiro

Rubi é uma linguagem fortemente orientada para objectos. De facto, (quase) tudo na Rubi é um objeto. A criação de objectos desnecessários pode custar ao seu programa uma grande utilização de memória adicional, pelo que deve ser evitada.

Para medir a diferença, utilizaremos um perfil de memória e um módulo Benchmark incorporado para medir o desempenho do tempo. 

Utilizar métodos bang! em cadeias de caracteres

requerer "memory_profiler"

relatório = MemoryProfiler.report do
dados = "X" * 1024 * 1024 * 100
dados = dados.downcase
fim

relatório.pretty_print

Na listagem abaixo, criámos uma cadeia de 100 MB e reduzimos cada carácter nela contido. O nosso benchmark dá nós o seguinte relatório:

Total atribuído: 210765044 bytes (6 objectos)

No entanto, se substituirmos a linha 6 por:

data.downcase!

Ler ficheiros linha a linha

Supostamente, precisamos de ir buscar uma enorme coleção de dados de 2 milhões de registos a um ficheiro csv. Normalmente, seria assim:

requerer 'benchmark'

Benchmark.bm do |x|
x.report do
Ficheiro.readlines("2mrecords.csv").map! {|linha|linha.split(",")}
end
fim

utilizador sistema total real

12.797000 2.437000 15.234000 (106.319865)

Demorámos mais de 106 segundos a descarregar completamente o ficheiro. Bastante! Mas podemos acelerar este processo substituindo o mapa! com um simples método enquanto laço:

requerer 'benchmark'

Benchmark.bm do |x|
x.report do
ficheiro = File.open("2mrecords.csv", "r")
while line = file.gets
linha.split(",")
fim
fim
fim

utilizador sistema total real

6.078000 0.250000 6.328000 ( 6.649422)

O tempo de execução diminuiu drasticamente desde que o mapa! pertence a uma classe específica, como Hash#map ou Matriz#map, em que Rubi irá armazenar todas as linhas do ficheiro analisado na memória enquanto for executado. O coletor de lixo do Ruby não liberará a memória antes que esses iteradores sejam totalmente executados. No entanto, a sua leitura linha a linha fará com que o GC reposicione a memória das linhas anteriores quando não for necessário.

Evitar iteradores de métodos em colecções maiores

Esta é uma extensão do ponto anterior com um exemplo mais comum. Como já referi, Rubi os iteradores são métodos de objeto e não libertarão a memória enquanto estiverem a ser executados. Em pequena escala, a diferença não faz sentido (e métodos como mapa parece mais legível). No entanto, quando se trata de conjuntos de dados maiores, é sempre uma boa ideia considerar a sua substituição por loops mais básicos. Como no exemplo abaixo:

numberofelements = 10000000
randoms = Array.new(numberofelements) { rand(10) }

randoms.each do |line|
#fazer algo
fim

e após a refacção:

numberofelements = 10000000
randoms = Array.new(numberofelements) { rand(10) }

while randoms.count > 0
linha = randoms.shift
1TP69Fazer alguma coisa
fim
"`

Utilizar o método String::<<

Esta é uma dica rápida e particularmente útil. Se acrescentarmos uma cadeia de caracteres a outra utilizando o operador += nos bastidores. Rubi criará um objeto adicional. Portanto, isto: 

 a = "X"
 b = "Y"
 a += b

Na verdade, significa isto:

 a = "X"
 b = "Y"
 c = a + b
 a = c

O operador evitaria isso, poupando-lhe alguma memória:

 a = "X"
 b = "Y"
 a << b

Vamos falar de Rails

O Estrutura Rails possui muitas "gotchas" que lhe permite otimizar a sua código rapidamente e sem grande esforço adicional. 

Eager Loading AKA n+1 query problem

Vamos supor que temos dois modelos associados, Post e Author:

class Author < ApplicationRecord
has_many :posts
fim

class Post < ApplicationRecord
pertence a :author
end

Queremos ir buscar todos os posts no nosso controlador e apresentá-los numa vista com os seus autores:

controlador

def index
@posts = Post.all.limit(20)
fim

ver

No controlador, ActiveRecord irá criar apenas uma consulta para encontrar os nossos posts. Mas, mais tarde, ele também acionará outras 20 consultas para encontrar cada autor de acordo - consumindo um tempo adicional! Felizmente, o Rails vem com uma solução rápida para combinar essas consultas em uma única. Usando a função inclui podemos reescrever o nosso controlador desta forma:

 def index
     @posts = Post.all.includes(:author).limit(20)
 fim

Por enquanto, apenas os dados necessários serão obtidos numa única consulta. 

Também pode utilizar outras pedras preciosas, tais como bala para personalizar todo o processo.

Chamar apenas o que é necessário

Outra técnica útil para aumentar a velocidade do ActiveRecord é chamar apenas os atributos que são necessários para os seus objectivos actuais. Isto é especialmente útil quando a sua aplicação começa a crescer e o número de colunas por tabela também aumenta.

Tomemos o nosso código anterior como exemplo e assumamos que só precisamos de selecionar nomes de autores. Assim, podemos reescrever o nosso controlador:

 def index
     @posts = Post.all.includes(:author).select("name").limit(20)
 fim

Agora damos instruções ao nosso controlador para saltar todos os atributos exceto aquele de que precisamos.

Renderizar parciais corretamente

Digamos que queremos criar um parcial separado para as nossas mensagens de exemplos anteriores:

À primeira vista, este código parece correto. No entanto, com um maior número de posts para renderizar, todo o processo será significativamente mais lento. Isto deve-se ao facto de Carris invoca a nossa parcial com uma nova iteração mais uma vez. Podemos corrigir isso usando o colecções caraterística:

Agora, Carris descobrirá automaticamente qual modelo deve ser usado e o inicializará apenas uma vez.

Utilizar o processamento em segundo plano

Qualquer processo que consuma mais tempo e não seja crucial para o seu fluxo atual pode ser considerado um bom candidato ao processamento em segundo plano, por exemplo, o envio de mensagens de correio eletrónico, a recolha de estatísticas ou a apresentação de relatórios periódicos. 

Ladokiq é a gem mais utilizada para o processamento em segundo plano. Utiliza Redis para armazenar tarefas. Também lhe permite controlar o fluxo dos seus processos em segundo plano, dividi-los em filas separadas e gerir a utilização de memória por cada um deles.

Escreva menos código, utilize mais gemas

Carris surgiu com um enorme número de pedras preciosas que não só facilitam a sua vida como aceleram o processo de desenvolvimentomas também aumentar a velocidade de desempenho da sua aplicação. Gemas como Devise ou Pundit são geralmente bem testadas no que diz respeito à sua velocidade e funcionam de forma mais rápida e segura do que o código escrito à medida para o mesmo fim.

Em caso de dúvidas para melhorar Desempenho do Rails, alcançar Engenheiros The Codest sair para consultar as suas dúvidas.

Ler mais:

Prós e contras do desenvolvimento de software Ruby

Carris e outros meios de transporte

Desenvolvimento Rails com TMUX, Vim, Fzf + Ripgrep