Mise en cache de l'accueil et autres pages communes

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Hello !

Il faudrait voir les moyens à notre disposition pour mettre en cache certaines pages/parties de pages telles que :

  • les menus déroulants tutos et forums
  • la page d'accueil, mais en laissant la citation aléatoire tranquille (1'30 pour avoir une réponse du serveur, c'est un peu lent)
  • liste des tutos (pareil, c'est lent)
  • liste des articles
  • le pied de page (la version du site)

Tout ça est à mettre en cache de façon assez forte. De cette façon un visiteur (non membre) aurait une page super rapide sur l'accueil. Un membre aurait un peu plus de délai à cause des diverses notifications (qu'il faudrait certainement optimiser d'une façon ou d'une autre, mais là ça rejoint plutôt le sujet de firm1).


Ça avait été mis puis retiré par firm1 suite à des bugs de clean du cache si je me souviens bien. On peut donc au moins mettre en place ce système là où ce soucis de serait pas visible.

Staff

C'est prévu, on a un ticket Github pour ça, mais y'a environ beaucoup de bugs à corriger avant d'en arriver là.

En fait, je ne comprends pas bien ce message :

  • Je n'ai pas du tout les mêmes temps de chargement que ceux que tu mentionnes (la page d'accueil répond chez moi en 350 ms, 450 ms si tu es connecté)
  • La notion de "cache à mettre en place là où les soucis de MAJ ne sont pas visibles" n'a pas vraiment de sens, puisque tout l'intérêt du cache est d'être mis en place exactement là où c'est visible
  • Il fait doublon avec le ticket #417

Rappel sur comment se met en place une stratégie de cache efficace :

  1. Liste des pages réellement appelées1 en grand nombre (à l'aide de logs ou d'outils d'analyse, en aucun cas à l'aide de suppositions)
  2. Étude des portions lentes sur ces pages
  3. Étude des impacts du cache sur ces parties (exemple : phrase aléatoire si on cache la home)
  4. Définition d'une stratégie de cache (renseignée en détail dans une documentation) :
    • Qu'est-ce qu'on cache ?
    • Sur quelles pages ?
    • Comment ce cache est mis à jour ? Invalidation, sur quels critères ? Expiration, combien de temps ?
  5. Mise en place
  6. Tests poussés pour éviter les bugs (protip : il y a toujours des bugs sur la v1 de l'implémentation)
  7. Mise en prod

D'expérience, toute tentative d'esquiver n'importe laquelle de ces étapes se solde par des problèmes de cache, qui sont parmi les pires qui puissent exister : l'utilisateur se les prends en pleine tronche, ils sont ultra-visibles, peuvent causer des fuites de données2 et sont ultra-chiants à déboguer.

Edit : précisions


  1. Quel que soit le type de site, dès qu'il y a un nombre pluriel de pages, les pages les plus utilisées et les fonctionnalités les plus utilisées ne sont jamais exactement celles prévues par les concepteurs. Il y a toujours un truc vu comme une killer feature qui n'intéresse personne, ou un détail à priori insignifiant qui est très utilisé. 

  2. Du genre "Oups, mauvaise clé de cache sur les droits, tout le monde a les droits staff". Ou plus probablement des forums privés qui se retrouvent public, ce genre de trucs. 

Édité par SpaceFox

Auteur du sujet

Mon but était de relancer la discussion là où elle est le plus simplement praticable (donc pas sur Github).

là où les soucis de MAJ ne sont pas visibles

C'est à dire, pas sur les notifications par exemple, qui changent tout le temps et où le cache aurait un rôle minime par rapport à la mise en cache des articles et tutos de l'accueil.

Pour le temps de réponse, c'est assez "aléatoire" là j'ai testé j'ai eu 670ms (bien trop long).

Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

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