Comment augmenter les performances de Rails

Rubis d'abord

Rubis est un langage fortement orienté objet. En fait, (presque) tout dans Rubis est un objet. La création d'objets inutiles peut coûter cher à votre programme en termes d'utilisation de la mémoire, c'est pourquoi vous devez l'éviter.

Pour mesurer la différence, nous utiliserons un memory_profiler et un module intégré d'évaluation des performances pour mesurer le temps de travail. 

Utiliser les méthodes bang ! sur les chaînes

nécessite "memory_profiler"

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

rapport.pretty_print

Dans la liste ci-dessous, nous avons créé une chaîne de 100 Mo et réduit chaque caractère qu'elle contient. Notre benchmark nous donne le rapport suivant :

Total alloué : 210765044 octets (6 objets)

Cependant, si nous remplaçons la ligne 6 par :

data.downcase !

Lire les fichiers ligne par ligne

Supposons que nous ayons besoin de récupérer une énorme collection de données de 2 millions d'enregistrements à partir d'un fichier csv. Typiquement, cela ressemblerait à ceci :

nécessite 'benchmark'

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

utilisateur système total réel

12.797000 2.437000 15.234000 (106.319865)

Il nous a fallu plus de 106 secondes pour télécharger entièrement le fichier. C'est beaucoup ! Mais nous pouvons accélérer ce processus en remplaçant l'élément carte ! à l'aide d'un simple alors que boucle :

nécessite 'benchmark'

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

utilisateur système total réel

6.078000 0.250000 6.328000 ( 6.649422)

La durée d'exécution a chuté de façon spectaculaire depuis la mise en place de la carte ! appartient à une classe spécifique, comme Hash#map ou Array#mapoù Rubis stockera chaque ligne du fichier analysé dans la mémoire tant qu'il sera exécuté. Le ramasse-miettes de Ruby ne libérera pas la mémoire avant que ces itérateurs ne soient entièrement exécutés. Toutefois, la lecture ligne par ligne permettra à la GC de relocaliser la mémoire des lignes précédentes lorsque cela n'est pas nécessaire.

Éviter les itérateurs de méthode sur les grandes collections

Il s'agit d'une extension du point précédent avec un exemple plus courant. Comme je l'ai dit, Rubis Les itérateurs sont des méthodes d'objets et ne libèrent pas la mémoire tant qu'ils sont exécutés. À petite échelle, la différence n'a pas de sens (et des méthodes telles que carte semble plus lisible). Cependant, lorsqu'il s'agit d'ensembles de données plus importants, c'est toujours une bonne idée d'envisager de la remplacer par des boucles plus basiques. Comme dans l'exemple ci-dessous :

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

randoms.each do |line|
#do something
end

et après le remaniement :

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

while randoms.count > 0
line = randoms.shift
# faire quelque chose
end
"`

Utiliser la méthode String::<<

Il s'agit d'une astuce rapide mais particulièrement utile. Si vous ajoutez une chaîne à une autre en utilisant l'opérateur += dans les coulisses. Rubis créera un objet supplémentaire. Ainsi, ceci : 

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

En fait, cela signifie ceci :

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

L'opérateur éviterait cela, ce qui vous permettrait d'économiser de la mémoire :

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

Parlons de Rails

Les Cadre Rails possède de nombreuses "gotchas"qui vous permettra d'optimiser votre code rapidement et sans trop d'efforts supplémentaires. 

Problème de chargement impatient AKA n+1 query problem (problème de requête)

Supposons que nous ayons deux modèles associés, Post et Author :

class Author < ApplicationRecord
has_many :posts
end

class Post < ApplicationRecord
belongs_to :author
end

Nous voulons récupérer tous les articles dans notre contrôleur et les afficher dans une vue avec leurs auteurs :

contrôleur

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

vue

Dans le contrôleur, ActiveRecord ne créera qu'une seule requête pour trouver nos articles. Mais plus tard, cela déclenchera également 20 autres requêtes pour trouver chaque auteur en conséquence - ce qui prend un temps supplémentaire ! Heureusement, Rails propose une solution rapide pour combiner ces requêtes en une seule. En utilisant l'option comprend nous pouvons réécrire notre contrôleur de cette manière :

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

Pour l'instant, seules les données nécessaires seront rassemblées dans une seule requête. 

Vous pouvez également utiliser d'autres pierres précieuses, telles que balle pour personnaliser l'ensemble du processus.

N'appelez que ce dont vous avez besoin

Une autre technique utile pour augmenter la vitesse d'ActiveRecord consiste à n'appeler que les attributs qui sont nécessaires pour vos besoins actuels. Ceci est particulièrement utile lorsque votre application commence à grandir et que le nombre de colonnes par table augmente également.

Prenons l'exemple de notre code précédent et supposons que nous n'ayons besoin de sélectionner que les noms des auteurs. Nous pouvons donc réécrire notre contrôleur :

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

Nous demandons maintenant à notre contrôleur d'ignorer tous les attributs à l'exception de celui dont nous avons besoin.

Rendre correctement les partiels

Supposons que nous voulions créer une partie distincte pour les articles des exemples précédents :

À première vue, ce code semble correct. Cependant, avec un plus grand nombre de messages à rendre, l'ensemble du processus sera nettement plus lent. Cela s'explique par le fait que Rails invoque notre partiel avec une nouvelle itération une fois de plus. Nous pouvons y remédier en utilisant la méthode collections caractéristiques :

Aujourd'hui, Rails déterminera automatiquement le modèle à utiliser et ne l'initialisera qu'une seule fois.

Utiliser le traitement en arrière-plan

Tout processus qui prend plus de temps et qui n'est pas crucial pour votre flux actuel peut être considéré comme un bon candidat pour le traitement en arrière-plan, par exemple l'envoi de courriers électroniques, la collecte de statistiques ou la fourniture de rapports périodiques. 

Sidekiq est la gemme la plus couramment utilisée pour le traitement en arrière-plan. Elle utilise Redis pour stocker les tâches. Il vous permet également de contrôler le flux de vos processus d'arrière-plan, de les diviser en files d'attente distinctes et de gérer l'utilisation de la mémoire pour chacun d'entre eux.

Écrire moins de code, utiliser plus de gemmes

Rails a mis au point un très grand nombre de gems qui non seulement vous facilitent la vie et accélèrent le processus de développement, mais augmentent également la vitesse de performance de votre application. Les gemmes telles que Devise ou Pundit sont généralement bien testées en ce qui concerne leur vitesse et fonctionnent plus rapidement et de manière plus sûre qu'un code écrit sur mesure pour le même objectif.

En cas de questions sur l'amélioration Performance de Rails, atteindre The Codest ingénieurs pour consulter vos doutes.

En savoir plus :

Avantages et inconvénients du développement de logiciels en Rubis

Rails et autres moyens de transport

Développement Rails avec TMUX, Vim, Fzf + Ripgrep