Le 10/02/2015 16:01, Wallace a écrit :
Sinon pour revenir à la demande initiale : - pour les statics le versionning est fait côté appli du client, la majeur parti des plugins d'optimisation font du minify css / js et ajoutent un timestamp ou autre.
Ah, bonne idée. Peut être que mod_pagespeed peut m'aider sur ce coup là !
- statics toujours les faire taper sur une autre url qui irait chercher directement sur les fs les données par des serveurs web only sans php et autre langage.
Tout ce qui implique de modifier les sites n'est pas envisageable dans mon cadre. Là, ce que tu proposes c'est d'avoir un vhost static.domaine.com, c'est bien ça ?
- pour le cache des pages c'est à l'applicatif de dicter les éléments qu'il a changé et d'appeler les caches pour invalider les pages mises en cache, ça c'est pour la partie juste page
On ne va pas cacher les pages, trop complexe. Après, ca vaut le coup d'introduire ces notions pour les CMS qui ont un plugin qui permettrait de le faire. Je pense qu'on va garder l'idée et l'introduire dans les bonnes pratiques sur les nouveaux hébergés.
Une solution ionotify oui et non ça marche par fichier et les proxy par url, si il y a de la réécriture d'url c'est mort tu ne sauras pas associer les deux. Comment vas tu savoir que /megamotclefseo/supermotclef/image.jpg correspond à /data/image.jpg? Pire si les données ne sont pas stoquées sur le docroot mais sur un répertoire privé où un appel au langage se fait de façon transparente? Genre ~/docroot/images/*.jpg rewrite sur ~/docroot/img.php qui vérifie les autorisations de l'internaute et va chercher le ~/private/*.jpg pour lui délivrer.
Bien vu ! Je pensais faire stocker le chemin complet au rproxy (via un header) pour retrouver le fichier de cache à invalider mais avec cette donnée, ca devient nettement plus chaud effectivement.
Tu as du mettre des reverse devant un hébergement mutualisé et dans ce cas un ttl court de 10/20 min devrait suffire car si l'élément est beaucoup demandé il suffira d'une requête pour le recharger. C'est ce que font les CDN lorsqu'on leur demande juste de mettre en cache les statics d'un site et que ce dernier n'est pas adapté à la mise en cache par un moyen ou un autre. Pour avoir mieux il faut que l'application derrière soit préparée à être mis en cache pour les statics et pour les pages qu'elle soit au courant du pool de proxy pour leur signifier les changements.
Donc on pourrait partir sur un cache de 10 min. Ce n'est pas l'idéal mais ça évitera 99% des demandes (et pour les 1% qui restent, on donnera l'url d'invalidation) et en cas d’événementiel sur un site, on limite déjà beaucoup la charge.
Merci pour cette analyse très complète. Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
