Problem has been solved! Please scroll down for results

I currently have wet-boew drupal running behind Varnish. Whenever a node is updated, Expire clears it from the cache as expected, however when a node is changed/created through deployment the cache seems to ignore it.

Has anyone encountered this issue? I can't seem to find any reference regarding it.

CommentFileSizeAuthor
#17 varnish_vanish.zip2.13 KBjoseph.olstad

Comments

kmtremblay created an issue. See original summary.

joseph.olstad’s picture

joseph.olstad
Primary language French
commented

Hi kmtremblay, yes I have observed this except instead of varnish expire it was boost and expire.

The explanation: the expire module during a hook_expire passes an array of expired urls , however the url that you deploy to is probably an internal domain , so expire expires the caches with the internal url that you with deploy.

the way around this is to write your own hook_expire so that your specific domains are all checked for the array of urls , so loop through the same array of expired urls but instead of just one loop, do it for each of your domains (including your external domains).

We created a very simplistic module called "boost_blast" that blasts everything , there's also a patch for boost_blast that is a start on a more granular approach.

See the sandbox project here and associated patches:

boost_blast sandbox project

add granularity

webpaving’s picture

webpaving commented

I have been working with the original requester on this issue, and in our case the target of the deployment is referenced using the name hostname/domain as the public-facing (cached) site.

kmtremblay’s picture

kmtremblay commented

Thank you, Joseph, I'll be looking into this today.

Right now we are using the following servers:

stage.example.com
prod.example.com

----------------------

Just noticed something this morning, after turning on debug for Expire module..

   Expiration was executed for the next URLs:

    URL: http://prod.example.com/en
    Wildcard: false
    Expired object: node
    --------
    URL: http://prod.example.com/en/demo
    Wildcard: false
    Expired object: node
    --------
    URL: http://prod.example.com/en/node/4
    Wildcard: false
    Expired object: node
    --------
    URL: http://prod.example.com/en/content/very-basic-page
    Wildcard: false
    Expired object: node
    --------

Correct me if I'm wrong, but that looks like it IS expiring the page I just deployed (the last one, very-basic-page). However this isn't

actually expiring it in varnish it would seem.

sylus’s picture

sylus commented

This sounds familiar to me as I think I have a few patches to both varnish + expire to get it working properly. However just to rule out this isn't related to?:

#2267305: Problem when clearing the cache of nodes using entity translation

webpaving’s picture

webpaving commented

sylus: We don't think it's the same as #2267305 ... but only because we have focused on testing every possible permutation on links to particular content via Varnish.

The only thing we _really_ know is that saving to the "Production" site directly clears the Varnish cache (via the Varnish module) but "deploying" does not.

I will set up a vanilla Drupal/Deploy configuration for testing. Perhaps this has nothing to do with the WxT distro.

joseph.olstad’s picture

joseph.olstad
Primary language French
commented

1) If your base_url is not set (like ours isn't) for varying reasons (plus we use multiple aliases/domain names , internal and external) for the same site, the caches are stored per alias/domain however the expire module will only return the expired URLs for the alias which the server was contacted with (in this case with deploy) , so if you are using more than one alias/domain then you'll have the issue of not having your caches cleared correctly.

2) if you are using entity translation (which the 4.x distro is using by default) then by default expire only expires the language that the deploy was requested from (english in your case) so the paths containing the french won't be expired. For this you'll want to follow closely #2267305: Problem when clearing the cache of nodes using entity translation

3) you'll have to make sure that your expire module configuration /settings is correct on not only the source site but also make sure it's installed correctly on the destination server and configured correctly.

to make 1 and 2 and 3 work together you'll likely have to create use hook_expire and place it in your custom_module as custom_module_expire as we have done with boost_blast (see boost_blast_expire for example) and enable it on the destination server , see my comment #2

the simplest way is to blow away the entire cache every time hook_expire is invoked as we're doing, however if you want a more granular approach we created a patch for boost_blast that is a kind of example for what you'd need to do , which would likely also need the patch for expire from issue #2267305: Problem when clearing the cache of nodes using entity translation

For us, our client updates content a couple times a day , the cache is completely blasted every time however even with this our server loads are almost nil even with 3 to 8000 hits per hour (hitting mostly the same handful of pages) because it's only 1 (multiplied by the number of unique pages of those 3 to 8000 hits) out on the hour that the content was updated that isn't cached (per page). The cache rebuilds quickly and our server cluster easily handles the load that we don't even feel the need to do a cache warming and haven't yet got around to implementing our granular approach because for our clients its more important that the content is up to date than having a little bit of extra load on the server to rebuild caches for pages that were not actually changed.

btw, some people think that varnish is the only cache daemon that serves from memory however with boost the first cache hit is loaded from the filesystem but the second hit is loaded from the web servers memory cache (apache , iis or nginx, they all have memory caches for files and boost creates the files) , we've done performance tests that show the second hit of a boost cached page is about 50% quicker than the first hit because the web server caches it into memory on the first hit and then the second hit is served directly from memory just like varnish does.

dddave’s picture

dddave commented

Sorry @kmtremblay. I've confirmed your account. Mollom is the worst sometimes.

kmtremblay’s picture

kmtremblay commented

@dddave Oh is that what that was lol. I wasn't receiving any notices etc so I thought it was just (somehow) something I did without realizing it. Thank you, sir.

@joseph.olstad Thank you very much for your detailed reply, my nerves are somewhat soothed (although I have to give some credit to the 4-day weekend heh). I'll go over this stuff today and try to see if I can make heads or tails of what's going on.

kmtremblay’s picture

kmtremblay commented

@joseph.olstad I have continued to pick away at this issue but I haven't been able to have any luck. My skills with writing modules are very basic at the moment since I've had to focus more on getting existing modules to work, I don't suppose there's any chance you might know what would be required for this to work using Varnish?

I tried using something to the effect of:

function varnish_blast_expire() {
	if (!module_exists('varnish') ||
		  (variable_get('varnish_cache_clear', VARNISH_DEFAULT_CLEAR) == VARNISH_NO_CLEAR) ||
		  (!variable_get('varnish_flush_cron', 0) && !lock_may_be_available('cron'))) {
		  return;
		}
	varnish_purge_all_pages();
}

To see if anything would actually happen...that was not the case.

joseph.olstad’s picture

joseph.olstad
Primary language French
commented

Hi kmtremblay, you may be in luck, if you contact this person, he has written a module called varnish_vanish that does almost the same thing as our boost_blast but for varnish and if you can convince him to publish it then you could run it.

joseph.olstad’s picture

joseph.olstad
Primary language French
commented
StatusFileSize
new varnish_vanish.zip2.13 KB

Ok, I asked for his permission and he gave me permission to share this custom varnish_vanish module that vanishes the caches according to configuration, you'll have to configure a sites.php file according to this document. https://api.drupal.org/api/drupal/sites!example.sites.php/7

This will help you configure multiple domain aliases cache vanishing.

here's the module.

Sorry, no README.txt file yet, you'll have to figure out how to use it. Perhaps next week we'll add documentation.

kmtremblay’s picture

kmtremblay commented

Thank you, Joseph, you may very well be a hero lol. I will look it over shortly and post results.

webpaving’s picture

webpaving commented

Joseph: The module from @delalis really broke the log jam for us on cache clearance for Varnish + Deploy.

Thanks for hooking us up.

In the end, I guess this isn't really a WxT issue.

The number of sites using the Deploy module(s) and Varnish must be fairly low for something like this to not be a well-known solution.

- Steve

joseph.olstad’s picture

joseph.olstad
Primary language French
commented

@webpaving , so you're saying that varnish_vanish works for you and your issues are now resolved?

webpaving’s picture

webpaving commented

Joseph:

Using varnish_vanish out of the box, we get the all-cache clearance for nodes that you referred to in your approach to "Boost Blast."

The varnish_vanish module doesn't clear cached menu content, but I think we are now on track for that.

Eventually, we want a granular (specific URL) purge ... but, again, this is probably not a WxT issue.

- Steve

joseph.olstad’s picture

joseph.olstad
Primary language French
commented

Hi @webpaving, ok, sounds like varnish_vanish is working successfully as designed/expected and that you've configured it correctly.

As for granularity, I mentioned this in comment #2 , our "add granularity" patch for boost_blast should/could inspire you to do something similar for varnish_vanish.

Let me know how that goes, should you make improvements to the varnish_vanish module we'd be very pleased to have a look.

I'll ask the author of varnish_vanish to publish it in his drupal.org sandbox , it could eventually be promoted from a sandbox project into an official drupal.org module project at some point.

sylus’s picture

sylus commented
Status: Active » Closed (won't fix)

Closing out as is more an issue with expire + varnish and looks like there is a workaround.

Thanks all!

kmtremblay’s picture

kmtremblay commented

@joseph.olstad, I just wanted to thank you for the help, things are going much smoother now. As far as the granular approach goes, I will be looking into this over time but for now it is just critical that the cache is actually clearing :)

That varnish vanish module was a life/hair saver. Is this a private module or does he have this up on GitHub? I'm making some changes and I would like to fork his repo if it exists.

kmtremblay’s picture

kmtremblay commented
Issue summary: View changes
Status: Closed (won't fix) » Active

I just wanted to make this active again to call to attention a change that solved our problem.

Problem
We had been able to successfully clear varnish on node deployment thanks to the varnish_vanish module @joseph.olstad provided. However, we have consistently been unable to have changes to the menu links reflected in the menus.

Solution
It turned out that it was WxT render caches holding on to that menu data. Clearing the cache is easy by clicking the "Clear WxT Render Caches" button under performance, but I simply tracked down the function attached to that form and copied the following lines into varnish_vanish_clear_all():

    cache_clear_all('wetkit_bean:slideout', 'cache', TRUE);
    cache_clear_all('wetkit_bootstrap:custom_search', 'cache', TRUE);
    cache_clear_all('wetkit_bootstrap:menu', 'cache', TRUE);

Our menus now update accordingly after a deployment is made that modifies menu links.

Thanks again for all the help, I hope this is as helpful to someone else as it was to us :)

sylus’s picture

sylus commented
Status: Active » Fixed

Thanks for the added information, glad it worked out for you!!! ^_^

joseph.olstad’s picture

joseph.olstad
Primary language French
commented

Hi @kmtremblay , good to learn about the positive results. The varnish_vanish module is not published elsewhere, feel free to fork it and I'd suggest adding it to your drupal.org sandbox as a new git project, as it IS a drupal contrib module its place is really on drupal.org . At some point it can be converted to a full project from a sandbox, so start with a sandbox project that is my advice. Let us know when your sandbox is ready and we can contribute to it later.

delalis’s picture

delalis commented

Hey All, glad it's working out for you. You have my permission to do whatever you want with the module, fork it, github it, go for it!

I've moved on to other things now so any further contributions you make are encouraged!

j_sauve’s picture

j_sauve commented

Indeed, @kmtremblay, we hope we can benefit from any improvements you make!

(also as we are just ramping up our Varnish install, I trust I can contact you for wisdom you have acquired in your experiences).

Cheers.

kmtremblay’s picture

kmtremblay commented

@j_sauve, feel free to contact me and I'll help with what I can :)

@delalis, thank you for permission, I will get on it first chance I get. I'm just getting the hang of drupal dev so it may take me a bit, but I'll get there!

@joseph.olstad, I'll post back here whenever I get that set up. Thanks for the tip.

kmtremblay’s picture

kmtremblay commented

The sandbox is now up: https://www.drupal.org/sandbox/kmtremblay/2701299

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.