Rails - L'utilisation de partiels ralentit-elle le rendu des vues?

16

J'ai des problèmes de performances sur une 3.1.0application Rails , maintenant j'ai fait des changements de dôme sur mes requêtes avec AR et ainsi, mais les vues prennent encore trop de temps à rendre, j'ai divisé les vues, les boucles et ainsi, sur de nombreux partiels qui sont rendus dynamiquement à l'intérieur des vues et à l'intérieur d'autres partiels.

C'est donc une mauvaise pratique d'avoir un grand nombre de partiels?

Dois-je réduire le nombre de partiels pour améliorer le temps de rendu des vues?

Merci

ruby-on-rails view rendering

— Mr_Nizzle
source

5

Je ne connais aucune différence de performance de rendu significative entre de nombreux partiels et une seule vue lorsque vous restituez le même contenu.

Évidemment, si vous ne rendez que certains partiels dans certains cas et d'autres dans d'autres cas, ce qui réduit efficacement le volume de rendu d'une vue spécifique, vous pouvez gagner en vitesse.

D'un autre côté, j'ai toujours considéré des résumés partiels qui devraient être utilisés au moins à partir de 2 endroits différents pour justifier leur existence. L'autre raison d'utiliser des partiels est lorsque vous souhaitez rendre la même vue mais charger différents partiels en fonction de votre logique métier.

MISE À JOUR:

Je ne peux pas proposer de mesure ou de chiffres concrets sur la vitesse de rendu. Si vous utilisez un partiel dans une vue, pour le rendre, vous appelez la méthode de rendu, il y a donc un deuxième appel de méthode. Comme je l'ai dit dans ma réponse, cela ne sert à rien, mais peut aider à accélérer un peu les choses.

Cependant, je n'ai jamais entendu parler d'un projet corrigeant son problème de performances en supprimant les partiels. Les partiels sont un bon moyen d'offrir un mécanisme de réutilisation aux vues et, du point de vue des programmeurs, ils doivent être utilisés pour cette étendue. Ils doivent être des résumés pour des concepts communs dans les vues.

J'ai travaillé sur un projet où les partiels étaient excessivement utilisés. Pas Rails, mais les mêmes principes MVC. L'utilisation de petits partiels pour tout ce que vous pouvez imaginer les rend difficiles à trouver lorsque vous commencez à en avoir des dizaines. Où rechercheriez-vous une entrée à modifier? Dans la vue? Dans un partiel? Dans quel partiel, il y a 4 partiels pour cette vue? ...

Après quelques refactorisations dures, à chaque mise à jour d'une vue, nous supprimions les partiels inutiles. Ils n'ont pas complètement disparu, mais il reste des résumés bien définis pour le projet. Ils représentent des éléments bien compris (comme un arbre pour une sorte d'objets, ou un type de liste spécifique) qui se répètent sous une forme ou une autre sur plusieurs vues. Je sais que si je vois un arbre, il y en a un partiel. Je sais que lorsque je vois un certain type de liste, il y en a une partielle. Je ne dois pas les traquer.

La lisibilité du code est la chose la plus importante que l'on puisse faire pour une base de code logiciel.

— Patkos Csaba
source

Donc, fondamentalement, si je n'ai pas vraiment besoin d'un partiel, si ce code ne sera pas réutilisé par un autre contrôleur ou rechargé dynamiquement, je ne devrais pas utiliser de partiels? et cela améliorerait le temps de rendu des vues?

— Mr_Nizzle

@Mr_Nizzle: J'ai mis à jour ma réponse pour couvrir les problèmes soulevés par votre commentaire. J'espère que cette explication développée est plus compréhensible ... Je viens de réaliser que mon deuxième paragraphe dans la réponse peut être mal compris.

— Patkos Csaba

Merci mec Code readability, c'est de cela qu'il s'agit.

— Mr_Nizzle

22

Je suis en désaccord avec les deux réponses. J'ai copié et collé le code d'un partiel dans la position qu'il est présent dans la vue parent partielle et avec 500 itérations, cela prend un énorme 600 ms sur le temps nécessaire pour rendre la vue. <% = render xyz%> est à mon avis très cassé.

Exemple, temps total pour rendre la vue:

Before:
5759.8ms
5804.2ms
5973.6ms

After:
5268.7ms
5201.6ms
5222.4ms

Diff = 5846 - 5231 = 615 ms

Édité

J'ai fini par désessayer tous les _partials dans le partiel _model et je suis descendu à ~ 2000 ms, moment auquel j'ai essayé de déplacer le _model partiel dans l'index, mais cela n'a eu aucun effet sur les temps de rendu, donc je suppose que c'est avec des appels au rendu imbriqué que le fait.

— AJP
source

Constatation intéressante sur imbriqué partiel. Voulez-vous dire annuler le séchage d'un partiel partiel de 600 ms et annuler le séchage de tous les partiels de 3800 ms? Pourriez-vous publier l'application de démonstration pour cela?

— lulalala

@lulalala oui exactement, et désolé je ne peux pas comme c'était pour mon travail et je l'ai maintenant déplacé de Rails vers Django donc même plus en contact avec ce code. En regardant Wyatt Barnett a répondu , je ne sais pas non plus si, en fait, sous le capot, les partiels faisaient des accès DB inefficaces que mon code non DRY évitait en quelque sorte.

— AJP

1

J'ai trouvé la même chose. La suppression du code des partiels et le déshydratation de la vue m'ont également permis d'augmenter les performances d'environ 450 ms.

— bcackerman

1

D'après mon expérience avec Rails avec des vues HAML, beaucoup de petits partiels ralentissent considérablement le rendu. Il semble y avoir une surcharge fixe pour chaque partiel, ainsi que le ramassage des ordures lors du rendu de nombreux partiels dans une vue. L'insertion d'un partiel utilisé dans un tableau de 50 éléments a réduit le rendu de la page de 500 ms.

— d4n3

2

Rails 4: Je viens de supprimer quelques milliers de partiels imbriqués sur une grande application et j'ai obtenu une énorme accélération. Je n'ai pas les chiffres, mais oui, si vous rencontrez des problèmes de performances, cela vaut la peine de supprimer certains partiels imbriqués pour voir si cela aide.

— Rick Smith

5

Pas un gars de rails, mais les vues partielles ne sont probablement pas le problème en soi. Il semble plutôt que vous fassiez un peu de SELECT N + 1. Regardez les choses du point de vue du serveur DB pour vous assurer que vous ne les battez pas en bouillie.

— Wyatt Barnett
source

2

Travailler sur une application Rails 4.2 en ce moment où une action lente qui prenait environ 745 ms en moyenne.

Lorsque je supprime le code des partiels et le place dans le modèle principal, le temps qu'il faut est désormais en moyenne inférieur à 25 ms.

Le nombre d'appels pour rendre les partiels n'était que de 29.

— Sammy Larbi
source

2

Même si vous n'avez pas de problème n + 1 et que vous faites tout le travail de base de données à l'avance (disons avec un CTE récursif), les partiels imbriqués sont toujours très lents. Haml et Erb me semblent tous les deux lents. Sur Rails 5.1.4, je vois quelques millisecondes pour chaque partiel, plus des partiels occasionnels qui sont bien pires (correspondant probablement à la récupération de place).

J'ai remarqué que si je renomme le partiel pendant qu'une de ces demandes est en cours d'exécution, j'obtiens immédiatement une erreur sur la façon dont le fichier n'est pas trouvé. Donc apparemment, Rails lit le disque partiel, le réanalyse et l'évalue pour chaque itération. Pas étonnant que ce soit lent!

— Paul A Jungwirth
source

0

Une grande partie de la lenteur observée dans les partiels imbriqués ne se produit que pendant le développement. Passez en production pour tester.

— Zapaf
source

Peut-être pourriez-vous expliquer pourquoi la version de développement est sensiblement plus lente et être plus nuancé quant au moment d'utiliser quel mode pour quels tests.

— Kain0_0

franchement, je ne connais pas tous les détails, je sais juste que j'avais les mêmes problèmes, et j'ai trouvé que c'était beaucoup mieux quand je suis passé à la production. Je peux deviner que, comme l'a remarqué Paul Jungwirth, la relecture du partiel et de la nouvelle analyse se produit pendant le développement lorsque les fichiers peuvent avoir changé.

— Zapaf