developer.jelix.org is not used any more and exists only for history. Post new tickets on the Github account.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Opened 15 years ago

Closed 9 years ago

#4 closed enhancement (fixed)

système de cache http

Reported by: d-m-p Owned by:
Priority: highest Milestone: Jelix 1.4
Component: jelix:core Version:
Severity: major Keywords: http cache
Cc: Blocked By:
Blocking: Documentation needed: no
Hosting Provider: Php version:

Description

A propos des zones et quoi qu'il en soit dans le détail que je ne connais pas encore.

Pour moi, quoi qu'il en soit, les choses question cache se résument en deux mots:

  • un client émet une requête GET
  • du contenu correspondant à cette requête est renvoyé avec un code OK, ou un NOT MODIFIED sans contenu, ce contenu étant déterminé par un certain nombre de paramètres "contenu administrateur" et "temporels".

Un système de cache côté client n'a donc qu'une question à se poser: le cache client mérite-t-il d'être rafraichi?

Côté serveur, il y a deux approches à mon avis:

  • soit, dès lors que l'on modifie "quelque chose" qui change le contenu renvoyé par une (des) requêtes GET particulière, il faut effacer le(s) cache(s) correspondant(s).
  • soit, on stocke dans la version cache l'ensemble des paramètres qui déterminent le contenu, plutôt qu'un hash du contenu généré.

Je n'ai rien contre les hashs, mais bon... A mon sens, il n'y a pas que la performance à prendre en compte (quand bien même il me parait certain que vérifier quelques paramètres est plus rapide que générer le contenu correspondant), mais la cohérence du bazar: ça n'a aucun sens de re-générer mille fois le même contenu...

  • dMp

Change History (10)

comment:1 Changed 14 years ago by laurentj

Une solution est à l'étude, et ce ne sera pas un plugin, mais une méthode dans jResponse.

En gros, c'est dans le code du controleur, de l'action, que le developpeur active ou pas explicitement le cache, et c'est lui qui décide implicitement si le contenu doit être rafraichit ou pas. Ça sera plus souple et moins usine à gaz dans jelix. En gros, le développeur fera cela :

function monaction(){
    // calcul de la date de dernière modification par le
developpeur
    // lecture en base de la date du dernier article de la
liste à afficher
   // par exemple...

    $dateLastModified=....

    $rep->getResponse('html');
    // on active explicitement le cache

    if($rep->activateHttpCache($dateLastModified)) return $rep;

    // ici génération du contenu habituel

}

en d'autre terme, on fourni la date de dernière modification du contenu à la méthode activateHttpCache. Celle ci renvoi true si, d'aprés les informations http, ce que le user a dans son cache est valide. Renvoi false sinon, et donc le developpeur génère son contenu comme à l'habitude. Dans les deux cas, le fait d'appeler activateHttpCache, génère les entêtes http adéquates conçernant le cache.

comment:2 Changed 14 years ago by laurentj

  • Component changed from jelix to jelix:core
  • Milestone set to Jelix 1.0
  • Owner set to laurentj
  • Status changed from new to assigned

comment:3 Changed 13 years ago by laurentj

  • Keywords http cache added

comment:4 Changed 13 years ago by laurentj

  • Milestone changed from Jelix 1.0 to Jelix 1.2
  • Summary changed from plugin de cache http to système de cache http

comment:5 Changed 13 years ago by laurentj

  • Priority changed from normal to highest

comment:6 Changed 13 years ago by laurentj

Inconvénient du système de cache http : ça ne concerne pas beaucoup d'utilisateurs. Au niveau trafic il y a beaucoup de gens qui viennent. de google, clic sur 2 ou 3 pages et reviennent jamais. De plus, dixit torgan, "souvent ça fait chier le cache des navigateur car en cas de nouvelle version du JS par exemple il est pas toujours mis à jour".

comment:7 Changed 11 years ago by laurentj

  • Documentation needed unset

bon, ce système peut toutefois être utile quand même pour les reponses genre rss.

comment:8 Changed 10 years ago by laurentj

  • Milestone Jelix 1.2 beta deleted

comment:9 Changed 9 years ago by laurentj

  • Owner laurentj deleted
  • Status changed from assigned to new

Une doc bien faite : http://www.mnot.net/cache_docs/

comment:10 Changed 9 years ago by laurentj

  • Milestone set to Jelix 1.4
  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.