evolix/wiki
22
0
Fork 0
Code Releases Activity

ajustement sur la gestion du cache / TTL

Browse source
This commit is contained in:
Gregory Colpart 2021-09-16 17:57:07 +02:00
parent 8b20489c1f
commit cb4be492c9
1 changed files with 40 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

51
HowtoVarnish.md
View file

@ -86,6 +86,22 @@ Pour vérifier ses règles (ceci est fait par défaut lors d'un redémarrage) :
# varnishd -Cf /etc/varnish/default.vcl > /dev/null
~~~
> *Note* : on peut ignorer le message du type :
>
> ~~~
> Message from dlopen:
> Could not load compiled VCL.
> dlopen() = vcl_.CflagTest.7071.1631806560.240605354/vgc.so: cannot open shared object file: Permission denied
> Running dlopen failed, exited with 1
> ~~~
Pour visualiser les règles "builtin" (les règles par défaut si l'on ne change rien) :
~~~
# varnishd -x builtin | less
~~~
### Gestion des logs
Par défaut, Varnish n'écrit pas ses logs dans un fichier, mais dans un segment mémoire, ce qui permet d'augmenter grandement les performances. Quand l'espace est plein, Varnish réécrit par dessus en repartant de l'origine, ce qui fait que la mémoire allouée pour les logs n'augmente pas. On peut voir des logs en direct avec les outils varnishstat (stats de Varnish), varnishtop (*top* pour Varnish), varnishlog (logs verbeux) ou varnishnsca (logs au format NCSA comme Apache) :
@ -351,17 +367,7 @@ return (restart);
## Gestion du cache
Par défaut Varnish respecte le comportement standard d'un reverse-proxy : pas de cache en présence de cookie, respect des entêtes HTTP envoyés par le client et backend : sa configuration par défaut devrait convenir pour les sites codés correctement ! L'avantage est que l'on peut facilement intervenir sur ce comportement standard pour ajouter des exceptions... si le code d'un site est incorrect.
Le temps de mise en cache par défaut peut être défini avec l'option `-t` à [#varnishd](). Par défaut il est à 120 secondes. On peut le changer avec `set beresp.ttl` :
~~~
sub vcl_backend_response {
set beresp.ttl = 1800s;
#unset beresp.http.expires;
set beresp.http.Cache-Control = "max-age=1800";
}
~~~
Par défaut Varnish respecte le comportement standard d'un reverse-proxy : pas de cache en présence de cookie, respect des entêtes HTTP envoyés par le client et backend : sa configuration par défaut devrait convenir pour les sites codés correctement ! L'avantage (ou le piège) est que l'on peut facilement intervenir sur ce comportement standard pour ajouter des exceptions... si le code d'un site est incorrect.
Grâce aux règles VCL on peut vraiment définir finement la mise en cache ou pas, en complément des entêtes de cache renvoyés par le code. On peut ainsi mettre en cache même si certains cookies sont présents, en les supprimant de la requête.
@ -410,6 +416,29 @@ sub vcl_deliver {
}
~~~
### TTL
Le temps de mise en cache (TTL) - si il y a mise en cache - est défini par la variable `beresp.ttl`.
Si le backend renvoie un entête HTTP `Cache-Control` contenant `max-age=` (ou `s-maxage=`) et/ou `Expires`, Varnish ajuste tout seul sa variable `beresp.ttl`.
On peut bien sûr définir `beresp.ttl`, mais attention cela va écraser la valeur déduite de Varnish, on conseille ainsi de faire :
~~~
sub vcl_backend_response {
# Default TTL if the backend does not send Expires or max-age/s-max-age headers
if (!beresp.expires && beresp.http.cache-control !~ "max-age=") {
set beresp.ttl = 1h;
#set beresp.http.Cache-Control = "max-age=3600";
}
}
~~~
À noter que l'on peut définir le TTL par défaut via l'option `-t` de [#varnishd]() mais on déconseille de le faire pour éviter toute confusion.
### Purge du cache
On peut purger le cache en ligne de commande.