Optimiser les templates

pour optimiser la lecture/execution

a marqué ce sujet comme résolu.

Coucou tout le monde.

C'est un sujet qui a fait surface récemment et dont on a reparlé dans le dernier ZM. D'ailleurs voici le morceau de conversation qui vous intéressera le plus à ce sujet :

<spacefox> Concernant le front, il a un impact indirect sur les perfs de part sa conception, ça tient en 2 points
<spacefox> 1. Les templates sont plein de conditions (on devrait en avoir le moins possible), je ne sais pas quel impact ça a sur les performances, mais je soupçonne que ça n'aide pas
<spacefox> 2. Comme les templates sont plein de conditions et découpés de manière assez étrange, on ne peut pas se servir du découpage pour mettre en place du cache facilement et ça c'est dommage.
<spacefox> DAns les projets sur lesquels je bosse, on voit les templates un peu comme des fonctions
<spacefox> tu connais les paramètres en entrée, et les mêmes paramètres = toujours la même sortie
<spacefox> donc si tu te démerdes pour respecter ces règles avec des templates avec peu de paramètres, tu peux souvent y coller du cache efficace
<pierre_24> En tout cas, dans la théorie, ça a de la gueule
<spacefox> sachant que les forums sont par nature très difficile à cacher, puisque très volatiles
<Eskimon> Donc il faudrait presque créer un ticket voire une ZEP sur "réfléchir à optimiser les templates" ?

De prime abord, deux solutions semblent voir le jour :

  • Comme vu ci-dessus, il faudrait revoir le découpage des templates : Oui mais comment ?
  • Et sinon en parrallèle attendre notre passage à Django 1.8 et activer Jinja21, moteur de template plus rapide que celui de Django natif

  1. En fait on pourrait déjà le faire avec Django 1.7 mais au prix de manipulations supplémentaire 

+2 -0

J'ai quand même une remarque par rapport à ce que dit spacefox

C'est clair qu'un template ayant un comportement similaire à une fonction (juste avec ses paramètres d'entrée) serai génial à l'utilisation. Mais le problème c'est qu'il y a plein de contraintes lié à l'utilisateur.
Si on prend les forums on peu se poser des tas de question du style: Est-ce un admin ? Est-ce l'auteur du sujet ? A t'il déjà voté pour ce message ? Affiche-t'il les signatures ? Est-ce l'auteur de ce message ?

Du coup… soit on a un template qui reçois pleiiin de paramètres soit on à pleiiin de petit template chacuns reçevant peu de paramètres.

+0 -0

Bah tu peux passer un objet ad hoc aussi (ça fait plus qu'un seul paramètre) :)

Du style UserTopic qui contient toutes les infos dont tu as besoin. Et tu reposes sur le equals(ou équivalent, une égalité fonctionnelle quoi, pas de références) pour savoir si t'as déjà la bonne info dans le cache ou non.

Mais bon, après y'a plein de trucs que je comprends pas trop dans cette histoire de cache de templates. Généralement ce qui est long c'est de compiler les templates, pas franchement de les rendre. SpaceFox tu peux donner des exemples de ce que tu appelles "templates comme des fonctions" (avec un moteur de template existant) ? Ca pourrait sûrement aider à proposer des solutions, j'imagine.

+2 -0

Bah en fait c'est surtout que l'objet en question devient la clef pour accéder à ton cache. Et tu reposes directement sur des méthodes d'égalité. Tu peux aussi construire une clef à partir de plein d'attributs différents, mais effectivement c'est moins lisible.

Mais bon, j'ai l'impression que le soucis est bieeeeeen plus complexe que ça. Et comme je connais pas Django, j'ai du mal à le saisir, malheureusement.

Je sais notamment qu'avec certaines technos que je connais mieux, le soucis est que certaines propriétés sont "lazy" et du coup l'accès à l'une d'elle provoque une requête de chargement des données. Quand on fait depuis l'intérieur d'un template, nécessairement, ça rallonge le temps de génération du rendu côté serveur.

Est ce que c'est applicable à Django ? Aucune idée malheureusement. J'espère que des experts passeront nous expliquer.

+0 -0

Bah en fait c'est surtout que l'objet en question devient la clef pour accéder à ton cache. Et tu reposes directement sur des méthodes d'égalité. Tu peux aussi construire une clef à partir de plein d'attributs différents, mais effectivement c'est moins lisible.

Mais bon, j'ai l'impression que le soucis est bieeeeeen plus complexe que ça. Et comme je connais pas Django, j'ai du mal à le saisir, malheureusement.

Je sais notamment qu'avec certaines technos que je connais mieux, le soucis est que certaines propriétés sont "lazy" et du coup l'accès à l'une d'elle provoque une requête de chargement des données. Quand on fait depuis l'intérieur d'un template, nécessairement, ça rallonge le temps de génération du rendu côté serveur.

Est ce que c'est applicable à Django ? Aucune idée malheureusement. J'espère que des experts passeront nous expliquer.

Javier

C'est en partie ça, le problème. L'orm de django fonctionne en lazy et du coup, si on fait pas très attention, on se retrouve avec plein de get dans les templates et plein de sous requête généré. C'est le cas aujourd'hui. Mais ça, c'est une petite partie du problème.

+1 -0

Je connais pas vraiment Django, donc ma suggestion est peut-être à côté de la plaque, mais en Rails, on a une librairie (bullet) qui intercepte toutes les requêtes SQL faites sur chaque page et affiche un popup si des requêtes de type n+1 sont détectées.
Je ne sais pas si la même chose existe pour Django, mais ça vaudrait le coup de regarder.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte