I'm assuming that, for simplicity's sake, Boost now flushes its cache when a user goes to the Performance page, and clicks the "Clear all caches" button, but this doesn't seem to be documented anywhere. Is that the preferred way of flushing Boost's static file cache now?

Comments

mikeytown2’s picture

Right now that is how its working. Is this ideal or do people want more control over the boost cache? I will put a link to the performance page on the boost configuration page.

Just wondering where was the first place you looked to flush the cache?

geerlingguy’s picture

Well, coming from D6, I was looking for the clear boost expired / clear boost all buttons, as were available in the D6 version... Maybe you could add at least the clear expired button, with a link to the performance page to clear all.

mikeytown2’s picture

Category: support » feature

Looks like D7 still flushes all caches on node_save via node_form_submit; so I still need separate control of the boost cache. Flushing the entire cache on node_save doesn't make a lot of sense once I get the expiration logic in the expire module. But for now this is a "safe" way to do it.

In short expect the flush boost buttons to return.

joelstein’s picture

I noticed that Boost for D7 removed the expiration logic, and it appears to be in the Cache Expiration module. However, it doesn't appear that Boost and Cache Expiration work together yet. Is this correct, or am I missing something?

matthewv789’s picture

One problem is the case of load-balanced web servers. In this case, whether the Boost cache is invalidated by a node update, pushing the "Clear all caches" button, or even an automatic expiration on cron (unless we guarantee that each web server runs its own cron separately), only the one web server knows about it; the other server(s) will happily continue serving up the static HTML cache files until ... when?

(Related issues: http://drupal.org/node/570458 and http://drupal.org/node/660598)

It seems to me that Cache Expiration could handle that by, for instance, triggering a drush cache clear command (or whatever) on the other server(s). So I think having Boost work together with Cache Expiration could provide some substantial benefits. Or feel free to suggest other options.

bgm’s picture

@ joelstein : Correct. Cache Expiration in itself only invokes the hook_cache_expire() of other modules, such as varnish. Boost could implement that hook, if it's not redundant. (disclaimer: I am not very familiar with the issue, I only looked at how the hook works)

@ matthewv789 : You could implement a module which would implement hook_cache_expire and hook_flush_caches, but I guess that involves having a way to talk to those servers using an http or ssh request. Imho, if you are using boost on a load-balancer setup, you should store the cache on a shared network disk such as NFS (if they can provide good performance). Where do you store images? -- in any case, this might be better off in a separate issue, since it is a tangent of the main issue.

geerlingguy’s picture

I've created a separate Boost Expire module for D7 that simply flushes all of Boost's static HTML cache every time a comment is posted/updated or a node is posted/updated.

There are some caveats to this approach, and I'm definitely open to changing the way the module works quite a bit, but for most of the sites on which I use Boost (few new nodes/comments vs. tons of traffic), this is a lot more helpful to me than manually hitting 'Clear all caches' every time I post a new node, update an old node, or want people to be able to see their comments.

For many of the sites on shared hosting, they're not even allowed to have cron run more than once every 15 minutes... and some sites are configured for every three hours, meaning new content could take that long to appear to the public/anonymous users! (But, not with this module enabled :).

bgm’s picture

@ geerlingguy : how does it compare with the expire module?

I did a quick comparison of both modules, and from what I understood, they are rather similar, but the expire module supports more use cases, but also can find "derivatives". For example, if a node is modified, the taxonomy pages for terms on that node will be flushed too.

Can you test / provide a patch that implements the hook_expire_cache() from the expire module? (even if it flushes the whole cache, we could refine it later.) It would be nice to finally fix this issue. (although I really only spent 5 minutes reading the code, and may be mistaking)

@ mikeytown2 : any hints?

geerlingguy’s picture

@bgm: the big difference right now is that it works with Boost in D7 ;-)

Mainly, I wanted something to flush caches on my sites when I posted new content. I'm hopefully going to do a bit more with it to make cache expiration more granular, but I'm still hoping to deprecate it in favor of the Cache Expiration module... However, I don't know of a timeline for Boost integration with it.

bgm’s picture

There's no timeline. It will move forward if you help to push it forward.

The official maintainer (mike) is busy, but I have commit access and can review/integrate patches (but my spare time is limited). Besides, you have already done part of the work, you seem like the most suitable person to test and integrate this. :)

Best practices for creating and maintaining projects

ywarnier’s picture

Hi guys,

Let me join (somewhat later) in the conversation...
I'm not sure I understand why Boost doesn't just hook node_update or node_save to delete the file or files it stored during the last generation of that node.

I guess there are tons of excuses, like "a node can respond to different routes, so we don't know if we'll delete all of them" or stuff like that, but how complex could it be to retrieve all possible routes and just delete them from the cache directory? Would this be the idea of an hypothetical hook_expire_page() you guys were talking about?

I will use the boost_expire for now to fix the issue, but I have about 4600 nodes on my site, so deleting the whole cache dir every time I edit one of the node is, indeed, not ideal.

ywarnier’s picture

I see a per-page cleaning is being discussed here: http://drupal.org/node/1401440, so maybe this discussion here is somwhat deprecated.

giorgio79’s picture

Status: Active » Closed (duplicate)