Sådan øger du Rails' ydeevne

Ruby First

Ruby er et stærkt objektorienteret sprog. Faktisk er (næsten) alt i Ruby er et objekt. Hvis du opretter unødvendige objekter, kan det koste dit program en masse ekstra hukommelse, så det skal du undgå.

For at måle forskellen bruger vi en hukommelse_profiler gem og et indbygget Benchmark-modul til at måle tidspræstation. 

Brug bang!-metoder på strenge

kræver "memory_profiler"

rapport = MemoryProfiler.rapport do
data = "X" * 1024 * 1024 * 100
data = data.downcase
end

rapport.pretty_print

I nedenstående liste har vi oprettet en streng på 100 MB og nedskrevet hvert tegn i den. Vores benchmark giver os følgende rapport:

I alt allokeret: 210765044 bytes (6 objekter)

Men hvis vi erstatter linje 6 med:

data.downcase!

Læs filer linje for linje

Angiveligt skal vi hente en stor datasamling på 2 millioner poster fra en csv-fil. Typisk ville det se sådan ud:

kræver 'benchmark'

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

bruger system total real

12.797000 2.437000 15.234000 (106.319865)

Det tog os mere end 106 sekunder at downloade hele filen. Det er ret meget! Men vi kan fremskynde denne proces ved at erstatte kort! metode med en simpel mens loop:

kræver 'benchmark'

Benchmark.bm do |x|
x.rapport do
file = File.open("2mrecords.csv", "r")
while line = file.gets
linje.split(",")
end
end
slut

bruger system total real

6.078000 0.250000 6.328000 ( 6.649422)

Køretiden er nu faldet drastisk siden kort! metode hører til en bestemt klasse, som f.eks. Hash#map eller Array#map, hvor Ruby vil gemme hver linje i den analyserede fil i hukommelsen, så længe den udføres. Rubys affaldsopsamler vil ikke frigive hukommelsen, før disse iteratorer er fuldt udførte. Men hvis man læser den linje for linje, vil GC flytte hukommelsen fra de foregående linjer, når det ikke er nødvendigt.

Undgå metode-iteratorer på større samlinger

Dette er en udvidelse af det forrige punkt med et mere almindeligt eksempel. Som jeg nævnte, Ruby iteratorer er objektmetoder, og de frigiver ikke hukommelsen, så længe de udføres. På en lille skala er forskellen meningsløs (og metoder som f.eks. kort virker mere læsevenlig). Men når det drejer sig om større datasæt, er det altid en god idé at overveje at erstatte det med mere grundlæggende loops. Som i eksemplet nedenfor:

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

randoms.each do |line|
#gør noget
end

og efter refaktorering:

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

while randoms.count > 0
linje = randoms.skift
#gør noget
slut
"`

Brug metoden String::<<

Dette er et hurtigt, men særdeles nyttigt tip. Hvis du tilføjer en streng til en anden ved hjælp af +=-operatoren bag kulisserne. Ruby vil skabe et ekstra objekt. Så dette: 

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

Det betyder faktisk det her:

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

Operatøren ville undgå det og spare dig for noget hukommelse:

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

Lad os tale om Rails

Den Rails-rammeværk har masser af "problemer", der giver dig mulighed for at optimere din Kode hurtigt og uden for meget ekstra arbejde. 

Eager Loading AKA n+1 forespørgselsproblem

Lad os antage, at vi har to tilknyttede modeller, Post og Author:

class Author < ApplicationRecord
has_many :indlæg
slut

class Indlæg < ApplicationRecord
hører til :author
end

Vi vil hente alle indlæggene i vores controller og gengive dem i en visning med deres forfattere:

controller

def indeks
@posts = Post.all.limit(20)
slut

visning

I controlleren, ActiveRecord vil kun oprette én forespørgsel for at finde vores indlæg. Men senere vil det også udløse yderligere 20 forespørgsler for at finde hver enkelt forfatter - og det tager ekstra tid! Heldigvis kommer Rails med en hurtig løsning til at kombinere disse forespørgsler til en enkelt. Ved at bruge omfatter metode, kan vi omskrive vores controller på denne måde:

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

Indtil videre vil kun de nødvendige data blive hentet i en forespørgsel. 

Du kan også bruge andre perler, som f.eks. kugle for at tilpasse hele processen.

Ring kun til det, du har brug for

En anden nyttig teknik til at øge hastigheden i ActiveRecord er kun at kalde de attributter, som er nødvendige til dit aktuelle formål. Det er især nyttigt, når din app begynder at vokse, og antallet af kolonner pr. tabel også stiger.

Lad os tage vores tidligere kode som eksempel og antage, at vi kun har brug for at vælge navne fra forfattere. Så vi kan omskrive vores controller:

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

Nu beder vi vores controller om at springe alle attributter over undtagen den, vi skal bruge.

Gengiv partialer korrekt

Lad os sige, at vi vil oprette en separat partial til vores indlæg fra tidligere eksempler:

 
  
 .

Ved første øjekast ser denne kode korrekt ud. Men med et større antal indlæg, der skal gengives, vil hele processen blive betydeligt langsommere. Dette skyldes, at Skinner påkalder vores partial med en ny iteration igen. Vi kan løse det ved at bruge Samlinger funktion:

 .

Og nu, Skinner finder automatisk ud af, hvilken skabelon der skal bruges, og initialiserer den kun én gang.

Brug baggrundsbehandling

Enhver proces, der er mere tidskrævende og ikke afgørende for dit nuværende flow, kan betragtes som en god kandidat til baggrundsbehandling, f.eks. at sende e-mails, indsamle statistikker eller levere periodiske rapporter. 

Sidekiq er den mest anvendte perle til baggrundsbehandling. Den bruger Redis til at gemme opgaver. Det giver dig også mulighed for at kontrollere flowet i dine baggrundsprocesser, opdele dem i separate køer og styre hukommelsesforbruget for hver enkelt af dem.

Skriv mindre kode, brug flere perler

Skinner kom med et enormt antal gems, som ikke kun gør dit liv lettere og fremskynder udviklingsprocessen, men også øger ydelseshastigheden i din applikation. Gems som Devise eller Pundit er som regel gennemtestede med hensyn til deres hastighed og fungerer hurtigere og mere sikkert end kode, der er specialskrevet til samme formål.

I tilfælde af spørgsmål til forbedring Rails' ydeevne, rækkevidde Codest-ingeniørerne ud for at konsultere din tvivl.

Læs mere om det:

Fordele og ulemper ved Ruby-softwareudvikling

Skinner og andre transportmidler

Rails-udvikling med TMUX, Vim, Fzf + Ripgrep