Closed (fixed)
Project:
Boost
Version:
8.x-1.x-dev
Component:
Caching logic
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
29 Nov 2022 at 21:38 UTC
Updated:
4 May 2024 at 19:54 UTC
Jump to comment: Most recent
Currently there is no cache invalidation except just purging all.
Activate this module and just see all files are there until a manual purge.
Integrate one or more cache configurable invalidation logic and options to clean use via cron.
-
Additional confguration options
Maybe some new file data to integrate with webserver.
Not decided yet.
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
c-logemannComment #3
c-logemannComment #4
c-logemannBoost caching can be seen and used (via webserver) as proxy cache. So I think it's a good idea to start to reuse system caching configuration on site /admin/config/development/performance
But instead of analyzing cache header in cached files it's easier to just use the creation time of the cached files. I can imagine that this can sometimes be a problem but only in very sophisticated setups and in any case this will be optional. So there will a Button to "Enable cron purge max_age".
Comment #6
c-logemannComment #7
c-logemannBecause drupal/php file search and deletion is not so fast I added possibility to use php exec with OS commands find and rm. And additionally or instead of cron there now also a drush command "boost:purge-max-age"
Comment #8
joseph.olstadA good start would be time based.
Any opinion on cache tag based invalidation? medium term/ long term?
Comment #9
c-logemann> A good start would be time based.
The code in this branch is already time based.
> Any opinion on cache tag based invalidation? medium term/ long term?
Currently D9+ boost is not a real cache backend where cache tags can be added and used. It has more common with cache proxies outside of Drupal like varnish. If possible I would like to avoid extra data in database or make this optional maybe with a sub module.
On the other side is boost still a module and so we have much more possibilities as external full html caches. So there is maybe a way to "hook" on cache invalidation of the core page caches and other core cache operations.
Comment #10
joseph.olstadFor D8/D9/D10 the advanced invalidation is provided by "purger"/"purge" module which handles cache tags.
In D7, it's the expire module.
The expire module has some pretty sophisticated cache invalidation capabilities and works fairly well.
Pretty sure that the expire module had support for boost or vice versa, although I recall using patches also.
For D10 boost, if cache tag support came in a submodule say for example called boost_purger that'd be really cool.
I recall assisting in the development of a D7 module called boost_blast which was designed to invalidate the entire boost cache, worked well for the odd time that some extra force was needed.
Keep up the great work on this initiative. I would hope that once we get a tagged release, people will start using it and then support will grow from there.
Comment #11
joseph.olstadI'm sure that boost_blast would be easy to port to D10, very simple module. the drupalmoduleupgrader should do most of the work.
once there's a tagged release of boost for D10, I will then port boost_blast to D10.
Comment #12
c-logemannThe time based purging code if this issue is very fast and I currently see no need of additional purging modules. And if there will be a cache tag implementation in future etc. I think we should also directly add purging features.
It seems your module boost_blast is pointing on the multisite functionality of the d7 version of boost. I remember the domain path part of D7 but this domain/multisite thing is not code on D9+ version yet. So I just added a new issue for that: #3368363: D10+ Multi-Domain and Multisite support
Comment #13
orkut murat yılmazWell, I would just like to add an idea. It could be another approach to integrate boost with ECA or rules.
Comment #14
c-logemann@Orkut Murat Yılmaz Please open an extra issue for this and please specify in which way you like to integrate. For me that has currently not a high priority especially because so many basic feature are still not stable.
Comment #16
c-logemann