Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generated varnish.vcl does not purge correctly #64

Open
fredvd opened this issue Nov 14, 2018 · 3 comments
Open

Generated varnish.vcl does not purge correctly #64

fredvd opened this issue Nov 14, 2018 · 3 comments

Comments

@fredvd
Copy link
Member

fredvd commented Nov 14, 2018

I've been debugging a site with Varnish 4.1.10 in front of a Plone 4.3 site where an image CT when replaced with new content, would not be purged from Varnish and still be served from the cache.

Purge requests are generated correctly from Plone, but even manual curl PURGE requests doesn't remove the item from cache. the purge request is however correctly logged when checking with varnishlog.

-   VCL_return     purge
-   VCL_call       HASH
-   VCL_return     lookup
-   VCL_call       PURGE
-   VCL_return     synth
-   VCL_call       SYNTH
-   VCL_return     deliver

Long debugging story short: the recipe generated varnish.vcl contains an empty vcl_hash {} paragraph. This causes the default.vcl from Varnish to be loaded, which adds the host name or IP to the hash calculation.

https://github.com/varnishcache/varnish-cache/blob/b2d2b6fe93b694ed5250b5d7af05f5a314f830d5/bin/varnishd/builtin.vcl#L84-L92

The problem: in most examples and even the helptext in the plone 4/5 caching control panel is is even suggested to add http://localhost:varnishport as the cache server address. Which can be different from which the normal request might end up in the cache.

when return(purge) is called from vcl_recv, vcl_hash() is called which looks up the item, purges it when return(lookup) is found and the executes vcl_purge(). The varnish documentation isn't really friendly here.

So you do see the notice that purging has happened in varnishlog, but Varnish didn't purge the right item or no item at all. Putting:

       hash_data(req.url);
       return(lookup); 
}

in the recipes's varnish.vcl for the hash function overrides the default.vcl and fixes the purging problem for me.

Maybe virtual hosting and adding hostname to the hash is a valid use case, but I think the most general use case is putting one Varnish instance in front of one Plone site and using the VHM components in the request URL to differentiate between the sites. Only if you don't use this recipe for Plone sites where you will use VHM almost obligatory

One temporary quick fix would be to add vcl_hash to the recipe config so we can
override it when needed, until there's some consensus reached if host/ip hashing is bad 95% of the time in the Plone stack (I think so), but are there other use cases to include hostname/ip in the cache hash I'm missing

I had the feeling already for a long time something was subtly wrong with purging but couldn't quickly figure out what it was, because everything seems to work fine, if it ain't broke, don't fix it:

With the default plone.app.caching rulesets for Varnish and split view caching nobody notices that the clean /path/to/image.png and its variations with /@@images/image/bla" are actually never purged, because logged in users/editors are not cached at all, and on saving the 'document' in which most images are used, it's html is regenerated with a image scale randomized url. And the pages are all last-modified checked with same default setup and also refreshed upon any change.

I've checked the varnish3 templates used by plone.recipe.varnish 1.x because purging does seem to work on some Varnish3 setups we still support, there a ban_url(req.url) is performed on band, only paying attention to the url and not hostname/ip

@cleberjsantos @jensens @mauritsvanrees

I want to:

  • add vcl_hash as a config parameter so people can fix this quickly in the recipe config if they think they have the same problem
  • have a new plone.recipe.varnish.release with the other fixes already on master
  • gather feedback and confirmation if this analysis is correct
  • decide if we should override vcl_hash by default in a next release
@fredvd fredvd self-assigned this Nov 14, 2018
@fredvd
Copy link
Member Author

fredvd commented Jan 4, 2019

vcl_hash option has been added (it was already there in the templates, but never read from the buildout config) and has been merged to master, will be available in releases > 2.2.0

Interim release available at http://pypi.zestsoftware.nl/public/plone.recipe.varnish-2.2.1.dev0+zest0.tar.gz .

To test hashing only based on the req.url, use something like in the varnish:configuration

[varnish-config]
recipe = plone.recipe.varnish:configuration
vcl_hash =
       hash_data(req.url);
       return(lookup);

@mamico
Copy link
Contributor

mamico commented Mar 9, 2019

@fredvd some years ago, annoyed by stale varnish content, I wrote https://github.com/collective/collective.purgebyid. The package solved my problems purging content with different host, vhm configs, custom image thumbs and views, ... Currently in varnish you need to use ban instead of purge (imho if your varnish server has enough memory and cpu is fine), but with small bit of changes and using https://github.com/varnish/varnish-modules/blob/master/docs/vmod_xkey.rst the use purge could be possible. I'm sorry for comment not directly related to this issue, but I think could be a useful hint.

@agitator
Copy link
Member

Can confirm this weird behavior and would support using a vcl_hash like this

sub vcl_hash {
    hash_data(req.url);
return(lookup);
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants