developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.
Opened 13 years ago
Closed 13 years ago
#448 closed enhancement (duplicate)
Amélioration mécanisme de rafraichissement du cache des zones
| Reported by: | sylvain261 | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | |
| Component: | jelix:utils | Version: | 1.0.1 |
| Severity: | normal | Keywords: | cache zone vérou |
| Cc: | Blocked By: | ||
| Blocking: | Documentation needed: | no | |
| Hosting Provider: | Php version: |
Description
Aujourd'hui, le cache des zones se rafraîchi automatiquement si le cache a expiré ou si le fichier caché a été supprimé. Le rafraîchissement du cache se fait "à l'initiative de l'internaute", j'entends par là qu'il faut qu'il y ai une requête nécessitant que la zone se charge pour que la zone recharge son cache. L'inconvénient c'est que si j'ai beaucoup de requêtes demandant le chargement de la zone juste au moment ou le cache expire j'ai de très forte chance pour que le cache de la zone soit rafraîchi plusieurs fois en parallèle. Pour une zone dont le contenu est coûteux a généré cela peut s'avérer problématique en terme de tenue en charge. Le pire scénario étant que compte tenu des accès concurrents pour rafraîchir le cache le temps nécessaire à la génération du contenu dépasse le délais de rafraîchissement...Là on est dans une situation où c'est comme si on avait pas de cache. Pour palier à cette problématique j'avais lu il y a longtemps une méthode à base de vérou. Ça consistait à mettre un lock d'écriture sur le fichier durant la génération du cache. Les autres process, si ils ont besoin de rafraîchir le cache mais qu'ils n'ont pas accès en écriture au cache, n'essaye pas de le rafraîchir et patiente jusqu'à ce que le fichier soit redevenu writable ce qui veut dire que le rafraîchissement est terminé et que donc le cache peut désormais être affiché. Si l'attente est trop longue vaut voir..on peut planter ou essayer d'afficher le contenu actuel du fichier.
Ce mécanisme un peu plus évolué me semble nécessaire pour le cache des zones compte tenu de la "cible" "site à forte charge" de Jelix.
Change History (5)
comment:1 Changed 13 years ago by laurentj
- Component changed from jelix to jelix:utils
- Priority changed from normal to low
comment:2 Changed 13 years ago by laurentj
Note que la fonction flock (pour verrouiller un fichier), ne fonctionne pas parfaitement sur tous les systèmes.
comment:3 Changed 13 years ago by bballizlife
- Documentation needed unset
Do we have to think more about this ticket ?
Arguments from laurentj make me say that the way the cache is generated for the moment works quite well.
In fact if there are no more arguments since 5 months in order to improve the zone cache process, i don't see why we should keep the ticket opened.
comment:4 Changed 13 years ago by sylvain261
In fact this issue is relative to ticket #540 and might be considered as duplicate.
comment:5 Changed 13 years ago by bballizlife
- Resolution set to duplicate
- Status changed from new to closed
Possible...
Là je ne comprend pas trop. Si une telle situation arrive, c'est que le développeur a mis un timeout trop petit. Si il met un timeout trop petit, je ne vois pas l'intérêt d'activer le cache. Bref, c'est à lui de corriger.
C'est ce qui se passe plus ou moins dans jFile:write (utilisé pour écrire le cache). Le contenu est généré dans un fichier temporaire (unique pour chaque demande de création), et ce n'est qu'une fois que le contenu est écris et le fichier temporaire fermé, que celui-ci est renommé avec le nom du fichier cache. Un renommage coûte beaucoup moins en temps qu'une écriture de fichier, donc les probabilités de conflits sont minimes. D'autant plus que sur les sites à très forte charge, il y a plusieurs serveurs (avec donc chacun leurs propres fichiers de cache), du load-balancing, voir même des systèmes de caches en aval.