Ticket #4 (assigned enhancement)

Opened 3 years ago

Last modified 8 months ago

système de cache http

Reported by: d-m-p Assigned to: laurentj (accepted)
Priority: highest Milestone: Jelix 1.2
Component: jelix:core Version:
Severity: major Keywords: http cache
Cc: Php version:
Review: Hosting Provider:
Documentation needed: Blocking:
Blocked By: 35, 172, 173, 465

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/12/06 13:07:00 changed 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.

10/25/06 13:09:23 changed by laurentj

  • owner set to laurentj.
  • status changed from new to assigned.
  • component changed from jelix to jelix:core.
  • milestone set to Jelix 1.0.

02/15/07 10:48:19 changed by laurentj

  • keywords set to http cache.
  • isp changed.
  • phpversion changed.

09/05/07 12:15:57 changed by laurentj

  • summary changed from plugin de cache http to système de cache http.
  • blocking changed.
  • milestone changed from Jelix 1.0 to Jelix 1.2.

09/05/07 12:48:32 changed by laurentj

  • priority changed from normal to highest.

01/10/08 12:20:56 changed 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".

Download in other formats: Comma-delimited Text Tab-delimited Text RSS Feed