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
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 escario@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/
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
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)...
Le 10/02/2015 12:16, Julien Escario a écrit :
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/
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 ?
Julien
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-con... https://www.varnish-cache.org/docs/3.0/tutorial/purging.html#bans
Julien
Liste de diffusion du FRsAG http://www.frsag.org/
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
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.
Au passage : Hello, je suis Luc/Sky/Framasky, adminSys dans une université et adminSys de l'asso Framasoft. Je me suis inscrit à cette liste (que je ne connaissais pas) suite à la faille Ghost et à son très bon traitement ici.
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 ?
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 :-)
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 :-)
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 :)
Le Tue, Feb 10, 2015 at 04:01:21PM +0100, Wallace [wallace@morkitu.org] a écrit:
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, ...)
On peut faire du stockage sur disque avec Varnish (c'est pas le but, mais on peut :)
- configuration bien plus simples pour 90% des cas
Plus simple, je sais pas. Mais plus naturelle, car pas dispersé dans les différentes fonctions vcl_*
- un côté sysadmin friendly bien plus fiable d'expérience
- une manipulation des headers / reponse plus simple à mettre en place
Bof. Varnish permet la manipulation de tous les entetes qu'on veut, dans le sens requete et dans le sens réponse. Avec nginx, il est facile d'ajouter des entetes, mais nettement plus compliqué de modifier les entetes existants.
- configuration ssl facile
pas eu l'occasion de tester. Mais le support de SSL est jeune dans Varnish, oui.
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, ...
Là où j'ajouterai un gros plus à nginx, c'est qu'il est simple d'effectuer des modifications (oui, c'est mal(TM)) du contenu qui transite, avec sub_filter Avec Varnish, il faut un module tiers pas stable, et à compiler en plus...
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
Pour ce genre de chose j'aurais pensé à mod_pagespeed en effet. *J'ai pas testé, mais* de ce que j'en sais, avec mod_pagespeed installé sur ton backend (Apache ?), tu as l'option de faire ajouter un hash aux url des fichiers statiques qu'il va prendre directement sur le fs. Du coup tu peux mettre un ttl à 6 mois et dès qu'un fichier change, son hash change, donc son URL aussi, et tous les niveaux de cache vont charger la nouvelle version. Inconvénient: ça modifie les pages html pour ajouter les hash aux ressources statiques Avantage: de fait c'est du versionning, donc ça invalide tous les caches, y compris ceux coté client (navigateur et proxy).
Fabrice
PS: c'est mon premier post sur cette liste. Bonjour à tous ! Je me présente: http://fr.linkedin.com/in/fabvincent
Le 11/02/2015 11:37, Julien Escario a écrit :
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à !
Le 13/02/2015 13:32, Fabrice Vincent a écrit :
Pour ce genre de chose j'aurais pensé à mod_pagespeed en effet. *J'ai pas testé, mais* de ce que j'en sais, avec mod_pagespeed installé sur ton backend (Apache ?), tu as l'option de faire ajouter un hash aux url des fichiers statiques qu'il va prendre directement sur le fs. Du coup tu peux mettre un ttl à 6 mois et dès qu'un fichier change, son hash change, donc son URL aussi, et tous les niveaux de cache vont charger la nouvelle version. Inconvénient: ça modifie les pages html pour ajouter les hash aux ressources statiques Avantage: de fait c'est du versionning, donc ça invalide tous les caches, y compris ceux coté client (navigateur et proxy).
Bonjour, Du coup, nous avons lancé des expérimentations en ce sens. A priori, dans notre contexte, le fait que mod_pagespeed modifie les pages HTML rendues est acceptable. Reste à tuner mod_pagespeed pour notre besoin.
Bonne journée, Julien
Bonjour,
Je serais preneur d'un court compte rendu de vos expérimentations... :)
Bonne journée Fabrice
Le 17/02/2015 13:41, Julien Escario a écrit :
Le 13/02/2015 13:32, Fabrice Vincent a écrit :
Pour ce genre de chose j'aurais pensé à mod_pagespeed en effet. *J'ai pas testé, mais* de ce que j'en sais, avec mod_pagespeed installé sur ton backend (Apache ?), tu as l'option de faire ajouter un hash aux url des fichiers statiques qu'il va prendre directement sur le fs. Du coup tu peux mettre un ttl à 6 mois et dès qu'un fichier change, son hash change, donc son URL aussi, et tous les niveaux de cache vont charger la nouvelle version. Inconvénient: ça modifie les pages html pour ajouter les hash aux ressources statiques Avantage: de fait c'est du versionning, donc ça invalide tous les caches, y compris ceux coté client (navigateur et proxy).
Bonjour, Du coup, nous avons lancé des expérimentations en ce sens. A priori, dans notre contexte, le fait que mod_pagespeed modifie les pages HTML rendues est acceptable. Reste à tuner mod_pagespeed pour notre besoin.
Bonne journée, Julien
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, ON tâchera de faire un petit topo une fois que l'on aura des résultats. Ca prend du temps de faire des essais et de les valider en douceur sur la prod.
Bonne journée, Julien
Le 02/03/2015 17:54, Fabrice Vincent a écrit :
Bonjour,
Je serais preneur d'un court compte rendu de vos expérimentations... :)
Bonne journée Fabrice
Le 17/02/2015 13:41, Julien Escario a écrit :
Le 13/02/2015 13:32, Fabrice Vincent a écrit :
Pour ce genre de chose j'aurais pensé à mod_pagespeed en effet. *J'ai pas testé, mais* de ce que j'en sais, avec mod_pagespeed installé sur ton backend (Apache ?), tu as l'option de faire ajouter un hash aux url des fichiers statiques qu'il va prendre directement sur le fs. Du coup tu peux mettre un ttl à 6 mois et dès qu'un fichier change, son hash change, donc son URL aussi, et tous les niveaux de cache vont charger la nouvelle version. Inconvénient: ça modifie les pages html pour ajouter les hash aux ressources statiques Avantage: de fait c'est du versionning, donc ça invalide tous les caches, y compris ceux coté client (navigateur et proxy).
Bonjour, Du coup, nous avons lancé des expérimentations en ce sens. A priori, dans notre contexte, le fait que mod_pagespeed modifie les pages HTML rendues est acceptable. Reste à tuner mod_pagespeed pour notre besoin.
Bonne journée, Julien
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
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 escario@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/
Le 10/02/2015 12:26, Damien Wetzel a écrit :
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 ?
Alors si ! Wordpress (et sûrement d'autres) notamment intègre un plugin qui permet de rajouter un header à une réponse du backend pour invalider le cache. Fastoche ;-)
Sauf que là, ce n'est pas une page servie par l'appli que l'on veut invalider mais un fichier statique et il n'y a pas de code entre le backend et le fichier pour informer d'une modif.
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.
OK, merci. Content de savoir que je ne suis pas le seul ;-) Mais j'ai peur que ca se transforme en usine à gaz.
On va faire un poc et on verra ce que ça donne.
Julien
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/
Bonjour,
Je ne sais pas si cela conviendrait mais il y a ça https://github.com/FRiCKLE/ngx_cache_purge Pour permettre à des clients de purger le cache (par IP par exemple). Ou avec Varnish https://www.varnish-software.com/static/book/Cache_invalidation.html
Florentin
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/
-
Boris Pigeot -
Damien Wetzel -
Dominique Rousseau -
Fabrice Vincent -
Florentin Clouet -
Julien Escario -
Luc Didry -
Ludovic Cartier -
Manu -
Mihamina RAKOTOMANDIMBY -
Pierre DOLIDON -
Wallace