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é
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 qu
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 prendr
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 mettr
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 pe
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, com
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 perf
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 : Hel
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
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 var
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, Ju
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, v
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 q
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
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 é
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.
Cordiale
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
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
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 fichie
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
20 matches
Mail list logo
