Re: [FRsAG] Nginx et son invalidation de cache
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/
Re: [FRsAG] Nginx et son invalidation de cache
Le 10/02/2015 16:14, Luc Didry a écrit : On 10/02/2015 16:01, Wallace wrote: Le gros inconvénient de Varnish c'est le tout en ram Je m'inscris en faux: on peut tout à fait demander à Varnish de cacher sur disque. Je crois même que l'exemple est dans le /etc/default/varnish de Debian, commenté en bas du fichier. Ce n'était pas le cas des précédents versions que j'ai installée, je vais me mettre à jour :) signature.asc Description: OpenPGP digital signature ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Nginx et son invalidation de cache
On 10/02/2015 16:19, Manu wrote: Le 10/02/2015 16:14, Luc Didry a écrit : Je m'inscris en faux: on peut tout à fait demander à Varnish de cacher sur disque. Je crois même que l'exemple est dans le /etc/default/varnish de Debian, commenté en bas du fichier. Mais y'a une perte de performance non ? acceptable ? Par rapport à Varnish en Ram ? Un poil, mais très acceptable (sans compter que c'est varnish ou plus de site vu qu'il s'écroulait sous la charge). De toute façon, vu que varnish accélere à mort le site qui était derrière, ram ou disque, c'est kif kif. Au passage : Hello, je suis Luc/Sky/Framasky, tous en coeur Bonjour Luc /tous en coeur Au passage, je suis Manu, AdminSys et réseau (tant qu'à faire) pour une asso développant l'usage des TIC et basée dans le Bas-Rhin :-) Hello Manu :-) -- Luc http://www.fiat-tux.fr/ Internet n'est pas compliqué, Internet est ce que vous en faites. signature.asc Description: OpenPGP digital signature ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] Nginx et son invalidation de cache
Bonjour, Maintenant que je parviens à gérer la durée de vie du cache nginx, je me heurte à un nouveau problème : son invalidation conditionnelle. Je m'explique : nous avons mis en place un frontal qui ne fait que du cache de ressources statiques avec nginx. Ca soulage les backend web et c'est plus rapide (on met le cache en ramdisk et on regarde pour du memcached). Tous contents, on est partis sur des valeurs astronomiques de cache des ressources statiques (genre 7 jours). Rapidement, on s'est fait engueulés parce que machin qui avait rajouté trois couleurs sur son bandeau de pub devait attendre 7 jours pour que ce soit visible. Alors on a rajouté la directive proxy_cache_bypass qui permet d'invalider une ressource cachées via une requête spécifique. Très bien, sauf qu'un jour on nous a demandé de pouvoir invalider le cache d'un grand nombre de fichiers d'un coup et on a dû scripter le truc avec du curl. J'aimerais bien passer la seconde là dessus en invalidant le cache d'un fichier statique automatiquement lorsque le fichier change sur le disque. La première qui me vient en tête est inotify : on monitore le filesystem et on génère une requête d'invalidation à chaque fois qu'un fichier statique change (avec le timestamp unix). Ca paraît faisable sur le papier mais je me demande si mon idée ne va pas se transformer en usine à gaz. Pour le moment, on a mis un cache à 5 min mais du coup, le cache commence gentiment à perdre de son intérêt, à part en cas de pic de consultation des sites. Du coup, est-ce quelqu'un a déjà rencontré/résolu ce type de problématique et peut partager ses conclusions ? Merci d'avance, Julien ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Nginx et son invalidation de cache
On 02/10/2015 02:33 PM, Julien Escario wrote: 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)... J'ai d'assez mauvais souvenirs sur mes premiers essais avec Varnish. Rien d'insurmontable mais bien écrire les règles de cache m'avait paru particulièrement compliqué. Après, en terme de perf, je n'ai pas de benchmark mais à mon avis, on joue dans le %. Et sur l'invalidation, on en revient toujours à la même chose : comment informer automatiquement le cache qu'il faut qu'il invalide tel ou tel fichier ? Automatiquement, je sais pas trop, par contre, dans Varnish il y a une command line: varnishadm. http://opensourcehacker.com/2013/02/07/varnish-shell-singleliners-reload-config-purge-cache-and-test-hits/ https://www.varnish-cache.org/docs/3.0/tutorial/purging.html#bans Julien ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Nginx et son invalidation de cache
Bonjour, As-tu envisager de prendre le problème à l'envers ? :-) Au lieu de partir dans le développement d'une usine à gaz, tu ne pourrais pas demander à tes clients de versionner leur bandeau de pub / images / fichiers statiques ? Tout est possible à ce niveau, rajouter -vXXX à la fin du fichier, le md5 du fichier etc etc... Comme ça tu leur laisse gérer totalement leur cache via une mise à jour de leur code / CSS. Le problème de vider le cache est que ça peut prendre un temps fou, lors de l'action, mais aussi pour la validation de ton script. Personnellement, c'est ce qu'on fait ici chez Watchever (service de SVOD allemand, concurrent européen de Netflix), donc autant te dire que la gestion du cache, c'est une partie de mon quotidien. Au final avec cette solution on a gagné du temps et de la souplesse ! Hésite pas si tu as des questions. ++ Le 10 février 2015 11:47, Julien Escario esca...@azylog.net a écrit : Bonjour, Maintenant que je parviens à gérer la durée de vie du cache nginx, je me heurte à un nouveau problème : son invalidation conditionnelle. Je m'explique : nous avons mis en place un frontal qui ne fait que du cache de ressources statiques avec nginx. Ca soulage les backend web et c'est plus rapide (on met le cache en ramdisk et on regarde pour du memcached). Tous contents, on est partis sur des valeurs astronomiques de cache des ressources statiques (genre 7 jours). Rapidement, on s'est fait engueulés parce que machin qui avait rajouté trois couleurs sur son bandeau de pub devait attendre 7 jours pour que ce soit visible. Alors on a rajouté la directive proxy_cache_bypass qui permet d'invalider une ressource cachées via une requête spécifique. Très bien, sauf qu'un jour on nous a demandé de pouvoir invalider le cache d'un grand nombre de fichiers d'un coup et on a dû scripter le truc avec du curl. J'aimerais bien passer la seconde là dessus en invalidant le cache d'un fichier statique automatiquement lorsque le fichier change sur le disque. La première qui me vient en tête est inotify : on monitore le filesystem et on génère une requête d'invalidation à chaque fois qu'un fichier statique change (avec le timestamp unix). Ca paraît faisable sur le papier mais je me demande si mon idée ne va pas se transformer en usine à gaz. Pour le moment, on a mis un cache à 5 min mais du coup, le cache commence gentiment à perdre de son intérêt, à part en cas de pic de consultation des sites. Du coup, est-ce quelqu'un a déjà rencontré/résolu ce type de problématique et peut partager ses conclusions ? Merci d'avance, Julien ___ Liste de diffusion du FRsAG http://www.frsag.org/ -- Ludovic Cartier ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Nginx et son invalidation de cache
Bonjour, il n'y a pas moyen d'integrer un API pour flusher le cache NGINX, pour que ca soit intégré au CMS de ton client des qu'il y'a une modification d'image ? Sinon la modification par inotify doit etre faisable, on y a pensé dans le cas ou on hébergerait l'origine CDN de nos clients. Cordialement, Damien Wetzel Ludovic Cartier writes: Bonjour, As-tu envisager de prendre le problème à l'envers ? :-) Au lieu de partir dans le développement d'une usine à gaz, tu ne pourrais pas demander à tes clients de versionner leur bandeau de pub / images / fichiers statiques ? Tout est possible à ce niveau, rajouter -vXXX à la fin du fichier, le md5 du fichier etc etc... Comme ça tu leur laisse gérer totalement leur cache via une mise à jour de leur code / CSS. Le problème de vider le cache est que ça peut prendre un temps fou, lors de l'action, mais aussi pour la validation de ton script. Personnellement, c'est ce qu'on fait ici chez Watchever (service de SVOD allemand, concurrent européen de Netflix), donc autant te dire que la gestion du cache, c'est une partie de mon quotidien. Au final avec cette solution on a gagné du temps et de la souplesse ! Hésite pas si tu as des questions. ++ Le 10 février 2015 11:47, Julien Escario esca...@azylog.net a écrit : Bonjour, Maintenant que je parviens à gérer la durée de vie du cache nginx, je me heurte à un nouveau problème : son invalidation conditionnelle. Je m'explique : nous avons mis en place un frontal qui ne fait que du cache de ressources statiques avec nginx. Ca soulage les backend web et c'est plus rapide (on met le cache en ramdisk et on regarde pour du memcached). Tous contents, on est partis sur des valeurs astronomiques de cache des ressources statiques (genre 7 jours). Rapidement, on s'est fait engueulés parce que machin qui avait rajouté trois couleurs sur son bandeau de pub devait attendre 7 jours pour que ce soit visible. Alors on a rajouté la directive proxy_cache_bypass qui permet d'invalider une ressource cachées via une requête spécifique. Très bien, sauf qu'un jour on nous a demandé de pouvoir invalider le cache d'un grand nombre de fichiers d'un coup et on a dû scripter le truc avec du curl. J'aimerais bien passer la seconde là dessus en invalidant le cache d'un fichier statique automatiquement lorsque le fichier change sur le disque. La première qui me vient en tête est inotify : on monitore le filesystem et on génère une requête d'invalidation à chaque fois qu'un fichier statique change (avec le timestamp unix). Ca paraît faisable sur le papier mais je me demande si mon idée ne va pas se transformer en usine à gaz. Pour le moment, on a mis un cache à 5 min mais du coup, le cache commence gentiment à perdre de son intérêt, à part en cas de pic de consultation des sites. Du coup, est-ce quelqu'un a déjà rencontré/résolu ce type de problématique et peut partager ses conclusions ? Merci d'avance, Julien ___ Liste de diffusion du FRsAG http://www.frsag.org/ -- Ludovic Cartier -- ___ Liste de diffusion du FRsAG http://www.frsag.org/ -- Pour une bonne sante en 2015 visitez http://www.sereni.tv/ ~ Damien WETZEL (ATANAR TECHNOLOGIES)(`-/)_.-'``-._ http://www.atanar.com . . `; -._)-;-,_`) (v_,)' _ )`-.\ ``-' Phone:+33 9 67 35 09 05_.- _..-_/ / ((.' - So much to do, so little time - ((,.-' ((,/ ~ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Nginx et son invalidation de cache
Le 10/02/2015 12:01, Ludovic Cartier a écrit : Bonjour, As-tu envisager de prendre le problème à l'envers ? :-) Au lieu de partir dans le développement d'une usine à gaz, tu ne pourrais pas demander à tes clients de versionner leur bandeau de pub / images / fichiers statiques ? Tout est possible à ce niveau, rajouter -vXXX à la fin du fichier, le md5 du fichier etc etc... Comme ça tu leur laisse gérer totalement leur cache via une mise à jour de leur code / CSS. Moui, ca serait la solution rêvée si on avait un temps soit peu de contact avec les devs des sites. Hors, là, il s'agit de plusieurs centaines de sites qui sont eux même clients de nos clients. Le temps de faire l'éducation de tout ce monde, j'aurais des cheveux blancs. Mais merci de ton idée mais dans notre cas précis, elle est difficilement applicable. Julien ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Nginx et son invalidation de cache
Bonjour. Je trouve que passer de 7 jours à 5 minutes c'est beaucoup de différence. Est-ce que des règles plus moyennes peuvent pas fonctionner ? (Etre ok pour les devs (même si pour eux ça sera toujours trop long) et être ok pour toi (ça dégomme pas trop tes backends)). Bon, sinon oui, versionning des fichiers ça pourrait être pas mal quand même. Pour inotify, j'ai des très bon retour en usage perso, mais vu que tu dis que tu as des devs de partout, je pense que tu dois avoir beaucoup de sites et du coup ça pourrait devenir vite une usine (à tester, ça peut toutefois être assez simple). Sinon autre piste : Si tu connais les IP des devs = pas de cache pour eux, seulement pour les visiteurs. Tu peux éventuellement faire des checks sur cookies je pense. http://nginx.com/resources/admin-guide/caching/ La dernière partie me semble adaptée à tes besoins. Tu leurs fais mettre un cookie à eux/à toi et eux n'ont pas de cache. Le 10/02/2015 11:47, Julien Escario a écrit : Bonjour, Maintenant que je parviens à gérer la durée de vie du cache nginx, je me heurte à un nouveau problème : son invalidation conditionnelle. Je m'explique : nous avons mis en place un frontal qui ne fait que du cache de ressources statiques avec nginx. Ca soulage les backend web et c'est plus rapide (on met le cache en ramdisk et on regarde pour du memcached). Tous contents, on est partis sur des valeurs astronomiques de cache des ressources statiques (genre 7 jours). Rapidement, on s'est fait engueulés parce que machin qui avait rajouté trois couleurs sur son bandeau de pub devait attendre 7 jours pour que ce soit visible. Alors on a rajouté la directive proxy_cache_bypass qui permet d'invalider une ressource cachées via une requête spécifique. Très bien, sauf qu'un jour on nous a demandé de pouvoir invalider le cache d'un grand nombre de fichiers d'un coup et on a dû scripter le truc avec du curl. J'aimerais bien passer la seconde là dessus en invalidant le cache d'un fichier statique automatiquement lorsque le fichier change sur le disque. La première qui me vient en tête est inotify : on monitore le filesystem et on génère une requête d'invalidation à chaque fois qu'un fichier statique change (avec le timestamp unix). Ca paraît faisable sur le papier mais je me demande si mon idée ne va pas se transformer en usine à gaz. Pour le moment, on a mis un cache à 5 min mais du coup, le cache commence gentiment à perdre de son intérêt, à part en cas de pic de consultation des sites. Du coup, est-ce quelqu'un a déjà rencontré/résolu ce type de problématique et peut partager ses conclusions ? Merci d'avance, Julien ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
