Utilisation de cache pour un rendu (beaucoup ?) plus rapide
Utilisation du cache de Django, voire Redis, ou autres… ?

Ce sujet est résolu, l'auteur de ce sujet a trouvé une solution à son problème.

MicroJoe

# il y a 2 mois et 9 jours

Bonsoir,

Comme vous le savez peut-être, j’aime bien optimiser Progdupeupl pour garantir un accès rapide à chaque page du site. Cela passe notamment par les améliorations suivantes :

  • Minimisation et réutilisation des résultats de requêtes SQL vers la base de données.
  • Compression des ressources (CSS et Javascript principalement ainsi que les quelques images PNG).
  • Mise en cache HTTP des ressources comme les images, les feuilles de style, les fichiers Javascript, …

Cependant, là où le site me semble commencer à peiner c’est la génération des pages. Même si le temps reste raisonnable de l’ordre de 1 seconde) il y a de nombreuses portions générées qui font des appels couteux à la base de donnée et qui pourraient être mémorisées, je pense notamment à notre jolie barre du haut qui peut faire deux dizaines de requêtes SQL pour vérifier les nouveaux messages/nouvelles réponses à chaque page.

Je pensais donc commencer par cette barre en utilisant la mise en cache native de Django, comme une sorte de test sur un élément qui consomme pour tester le temps gagné (et ça pourrait être assez bluffant d’après ce que j’ai vu).

Cependant, il serait également important d’envisager de cacher le rendu HTML produit par la source Markdown, que ce soit au niveau des tutoriels ou autre. Une technique bête et méchante (que j’envisageait jusqu’à présent) serait la suivante : rajouter un champ dans chaque modèle qui possède une source Markdown, cependant, j’y trouve pas mal d’inconvénients :

  • On explicite directement la mise en cache au niveau des données, ce qui n’est vraiment pas très joli.
  • Il faut rajouter ce comportement pour chaque classe qui utilise un champ Markdown, autrement dit pas mal de modèles, ce qui peut représenter un travail non négligeable au niveau du code source.
  • En procédant comme ceci, au final on fait toujours un appel à la base de donnée.

Je pensais à ceci, qui a l’air de se faire sur les gros sites : utiliser une base NoSQL comme Redis afin de cacher le contenu généré, c’est ce que semble faire StackOverflow par exemple. Ça permettrai des accès rapides et ne serait présent que sur le serveur de production, afin de ne pas s’embêter à faire du caching sur la version de développement ; après ça nécessite néanmoins une adaptation du code mais ça me parait plus propre que l’alternative précédente.

Des avis éclairés sur le sujet ? Il me semble que victor aurait son mot à dire étant donné qu’il s’est attaqué à de la mise en cache sur son site qui reçoit 10x plus de visiteurs que PDP.

MicroJoe

# il y a 2 mois et 9 jours

Bon, je viens de cacher la barre pour 2 minutes, vous devriez sentir une énorme différence sur la vitesse de chargement des pages (du moins personnellement c’est ce que je ressent). Pour l’instant, ça utilise la mémoire RAM sans memcached car j’avais la flemme de l’installer ce soir ; ça attendra la prochaine VM (oui, PDP devrait bientôt (encore) changer de VM, pour une architecture plus propre notamment).

J’ai également mis en cache les flux RSS/ATOM pour 5 minutes, étant donné que ce sont les URLs qui sont le plus demandées d’après les statistiques, autant essayer de faire souffler un peu le serveur à ce niveau.

fscorpio

# il y a 2 mois et 8 jours

MicroJoe a écrit :

  • Compression des ressources (CSS et Javascript principalement ainsi que les quelques images PNG).

Pour les PNG/JPG y a trimage qui fait un bon boulot.
Par contre, vu la faible quantité d’image, le gain sera minime…

MicroJoe

# il y a 2 mois et 8 jours

C’est déjà compressé en fait avec PNGOptimizer.

fscorpio

# il y a 2 mois et 6 jours

Ah, j’ai testé avec le petit minou en haut à gauche (topbar.png), trimage me donne un gain de 25.5% par rapport à sa taille actuelle, PNGOptimizer (utilisé à partir de ce site) me donne un gain de 19.8%.

Sur ce coup Trimage > PNGOptimizer. :)

MicroJoe

# il y a 2 mois et 5 jours

Tu peux faire une pull request avec les nouvelles images compressées si tu veux. ^^

MicroJoe

# il y a 2 mois et 5 jours

Bon, en fait j’avais activé par mégarde le cache sur tout le site au lieu de le limiter aux éléments précis ; c’est chose réglée et on ne devrait plus avoir de vilains bugs sur le forum. La barre du haut devrait ne plus avoir de problème au niveau des sujets suivis car dès que l’on visualise un sujet suivi avec de nouvelles réponses, le cache de la barre du haut est supprimé et Django doit alors générer un menu déroulant tout frais qui prendra en compte le fait que vous aurez lu le sujet.

Il reste encore deux-trois améliorations à faire (notamment sur la page d’accueil) mais sinon tout se profile plutôt bien !