Per #1893882: Boost cron cache expire only on default domain Boost does not intentionally clear the cache for all the domains on a site. Is it intended, then, that we do this via separate cron calls?

I'm using Domain Access module, and all the sites are on the same infrastructure and backend. It seems odd to call cron for each domain at the same time, so I'm staggering them. But now if I add another domain I'll have to manually update my crontab, which seems wrong.

Comments

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Closed (works as designed)

The issue is that you are assuming that all sites are like your own, one could have a 2000 page site for information about plumbing which is never updated and a 5 page site with constantly changing information in the same server. The 2000 page site would be wiped out and have major performance issues if the cache were cleared entirely because the 5 page site needed changing.

Personally I've never really seen the need to clear the cache at all unless a site's layout is changed the boost crawler will regenerate any updated/ inserted. deleted pages and their family of pages. Altering the crontab for each site is correct for drupal as a whole.

Offlein’s picture

Offlein commented

...Not assuming anything! Just asking what is proper!

I did not read carefully enough and was not aware that Crawler would do that. Although I had an issue a while back where my odd server configuration precluded me from using Boost Crawler (...maybe it had a required module that didn't work, or something? I'll look into it again.)

Anyway, it specifically came up this time because I modified a CSS file which had a styling bug in it. My script clears the cache on one domain manually and that's the one I apparently tested on, forgetting that the others wouldn't get pushed the change.

Anonymous’s picture

Anonymous (not verified) commented

Sorry probably a bit snippy then, lots of things to consider about how people install drupal. If the crawler doesn't work for page regeneration then I'll have a look the only "problem" I find with it is that it is tied to cron runs and some non-changing sites have cron running on such a schedule that the pages aren't regenerated by the crawler, but by anonymous users which then shows up in the logs as an "error" even though a fresh page has been generated. There's a list on 7.x for what is required by boost_crawler, Cache expiry module (listed under the expires project name) and the httprl module.

Offlein’s picture

Offlein commented

Hi Philip. No worries at all! Do you realize how slowly most maintainers respond to things tagged "Support request"? The way I see it, if you're responding to people's posts within two hours you've basically got license to say terrible things about their deceased mothers as long as your reply's in earnest.

It was HTTPRL -- I had reports of errors about not being able to connect to the server. But I have a feeling that this was all a misunderstanding because the staging environment was behind an HTTP Authentication wall. I'll re-enable this and give it another go.

But in the end, that won't help for code pushes like my issue. I should simply be diligent about it, though -- an acceptable solution.

Anonymous’s picture

Anonymous (not verified) commented

staging environment was behind an HTTP Authentication wall

That sounds like the correct diagnosis, one thing to note, bugs the hell out of me. On the /admin/reports/status page httprl does a self test, this frequently leads to a suprious error in the logs, basically it's says to itself "do I work", "look for a HTTP 200", "generate a blank page", which then throws an error through boost and the theme_render functions as it's rendering a nothing to nowhere. Nothing to worry about but took me ages to work out the underlying cause.

*note to self* maybe I should do something about that like excluded the page or something.

Offlein’s picture

Offlein commented

Very interesting! Well this has been highly edifying. Thank you for your time!