Le 10/02/2015 12:21, Pierre DOLIDON a écrit : > Pourquoi monter du cache Nginx dans un ramdisk ? Pourquoi ne pas > plutôt utiliser Varnish (-s malloc,12G par exemple), puis utiliser son > ACL "purge" et/ou son secret... C'est quand même plus prévu pour que > NginX (et il m'avait semblé lire que varnish était plus performant que > nginx pour du cache statique)... > Varnish et Nginx en reverse proxy cache c'est équivalent pour 90% des cas. Les avantages de Nginx sur Varnish c'est : - storage persistant possible (disk, redis, ...) - configuration bien plus simples pour 90% des cas - un côté sysadmin friendly bien plus fiable d'expérience - une manipulation des headers / reponse plus simple à mettre en place - configuration ssl facile
L'avantage de Varnish pour les 10% restants : - pouvoir scripter des règles assez complexes Si le visiteur vient de tel endroit avec tel ou tel cookie ayant telle valeur alors il va sur tel backend et on réduit le cache à temps de secondes ou pas du tout sur telle ou telle ressource, ... Le gros inconvénient de Varnish c'est le tout en ram, ok c'est rapide mais quand y a des gros sites derrières, un cold restart des reverses n'est plus envisageable sans mettre à plat les backends et j'ai déjà vécu plusieurs fois des prods tomber parce que des Varnish avaient été redémarrés. 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. - 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. - 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 - pour les statics il reste une méthode crade que j'ai mis en place pour un site tellement monstrueux en nombre de page que même Google n'a jamais parcouru toutes les pages. Comme le temps de génération des pages était trop long à la première navigation j'ai mis en place un pool de crawler web qui demandaient la page et la mettait dans le cache. Les proxy avait un ttl plus élevé que la fréquence à laquelle au moins un crawler devait repasser. Quand la page était à nouveau demandé sans passer par les proxy, le cache était écrasé par le crawler. Mais bon là c'est un exemple complexe où j'avais une garantie que les pages étaient modifiées qu'une fois par an et encore. Lorsque de nouvelles pages / modification avaient lieu les urls étaient en top liste des crawlers. Avec ce système on avait plusieurs centaines de millions de page html en cache et forcément à jour avec un ttl de 6 mois pour les proxy. 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. 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. A en discuter
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
