search

varnishcache / pkg-varnish-cache

Package building scripts for official Debian and Redhat packages of Varnish Cache.
21 stars 30 forks source link

`varnishreload` should clean up old VCLs by default #171

Open Bilge opened 8 months ago

Bilge commented 8 months ago

Although varnishreload supports cleaning up after itself (with the -m option), most people will probably never discover this, and regardless of whether they do or not, it seems to me it should be the default behaviour to keep a maximum (e.g. of 5 or 10) VCLs around to avoid memory and disk usage growing indefinitely.

Personally I don't really see the need to keep any old VCLs around, because it seems to me the normal use-case should be deploying a new VCL and reloading each time one wishes to make a change, even if that change happens to be a rollback, rather than attempting to reference one of the pseud-randomly generated VCL reload names and hoping you happen to roll back to the correct one despite the unclear moniker, but I respect there may be use-cases I have not considered that find value in such rollback facility. Nevertheless, it should not be practical to ever roll back more than 5, conservatively, or 10 at the absolute most, so the default should be somewhere in this region.

dridi commented 8 months ago

VCL names are not pseudo-ramdom, they are timestamped so if you can trace reloads back to operations, then it shouldn't be a problem to know where to roll back. If you deploy, monitor the change for a while, and then decide whether to stay on the new one or roll back, chances are that most of the time you are rolling back to the previous one.

If you can't trace reloads back to operations, there is little this script can do for you. A problem we've observed is that certain users will issue a systematic reload every five minutes for example, whether the VCL files changed or not, so regardless of how many we retain, there is eventually nothing to roll back to.

The script shouldn't clean things up by default, we aim to provide mechanism, rather than policies.

https://varnish-cache.org/docs/7.4/dev-guide/index.html#architectural-stuff

The systemd service we ship could have a -w option, at the same time it's easy to override ExecReload. The question then is how many VCLs to retain and it's a questing more difficult than it looks. A better approach would likely be to retain a little more than what seems sensible, to give a larger safety net to shops needing more than the average.