The views module generates pages and blocks whose contents can change when the following events happen:
1. A view's filters, arguments, default sort order, nodes-per-page, or text fields are changed.
2. A node's fields are changed in ways that affect it's inclusion in a view.
3. The passage of time such that nodes are added or removed from a view based on their time-related fields.
To handle #1, I'm looking to add a submit hook via hook_form_alter to the views edit form.
To handle #2, I'll probably do the same but for the node edit form.
To handle #3, I'll likely add logic to boost's init hook.
All of the above could prove to be computationally heavy, especially if a site has a large number of views. Depending on how it plays out, I might add a setting for how aggressively to keep views cached.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | boost_views.tgz | 2.57 KB | tim cullen |
| #1 | boost.api_.inc_.diff | 483 bytes | tim cullen |
| #1 | boost.block_.inc_.tgz | 1.71 KB | tim cullen |
Comments
Comment #1
tim cullen commentedAttached are the following files:
boost_views.tgz
boost.block.inc
boost.api.inc.diff
Boost Views is a submodule of boost that provides view-related intelligence for more aggressive and timely cache expiration. More on this module below.
boost.block.inc is an include which handles the expiration of cached pages which contain certain blocks. Boost Views (and Boost Nodequeue) rely on it.
boost.api.inc.diff is a small patch to boost.api.inc, mainly changing boost_cache_expire() so that it returns a boolean based on whether there was a file present to be deleted.
The Boost Views module is for site admins who want to aggressively keep their cache current with respect to the manifestations of the views module on their site. It listens for changes to views either through a submit hook appended to the views edit form and through hook init. Changes to views prompt the expiration of the view's page and the pages on which blocks driven by this view are present.
The init hook uses a poorman's cron style timecheck to execute a wget call against a callback every minute (the interval is configurable). The callback checks for cached queries or builds queries for all views, and checks the result of each against a simple cache. Changes to the results prompt an expiration of the view. The callback runs in the background, so the pageview that triggered it is not delayed if callback takes a significant amount of time to execute.
(N.B.: Make sure to set the definitions for your server's wget path and subcron interval at the top of boost_views.module. Also, boost_views ideally lives within the boost module's directory. boost.block.inc needs to be in the boost directory and is required by boost_views.)
This is obviously just a first attempt. I welcome any and all suggestions, comments, patches advice and rearrangements.
Comment #2
moshe weitzman commentedAny comments on this pioneering work?
Comment #3
e5sego commentedGood idea.
But what I also miss is that cached views pages are re-created, after a node listed in the view is changed. The boost module does not tell about that issue, might it should behave like this already?
Comment #4
lapith commentedI would have to agree with sebastiang.
While this is a good first step, it really doesn't address the more important problem that I see with views and boost integration. As a site administrator, if I change a view I can easily delete the cache, but as a content manager I do not have access to do the same thing.
If I delete/edit a node that is being referenced by a view it would seem more important that the cache for the page that the view is being displayed on be refreshed. Let us assume for a moment that the front page is displaying a view of the top 10 images on a site. The front page is then cached with this view, but unfortunately there is an inappropriate picture being placed on the home page. The content manager quickly goes in to delete the image node, which also deletes the image file on the server. The front page now has a blank space since the image is returning a 404 error.
I would be interested in thoughts as to how one could go about solving this problem.
The first thing that comes to mind is the possibility of on node update/creation/deletion, the pages in which views are placed that include that content type are expired.
Comment #5
moshe weitzman commentedThere is no way to "the pages in which views are placed that include that content type are expired.". Views are lot more varied than just based on content type.
Comment #6
mikeytown2 commentedI'm playing around with a button for the boost block that will delete that pages cache #368366: Boost Block - Button: Flush Page's Cache. Also in that same vain is a action that would be useful with the rules module. The for this would involve knowing where and how each content type is used, so when the node changes it flushes these 10 other pages as well. Related for 6.x: #453908: Hook for panel node types - expiration of static cache; panel containing multiple nodes.
Comment #7
lapith commented@moshe weitzman: I agree, a more automated solution probably isn't going to be possible for this problem. What do you think about the possibility of there being an admin that would allow a site administrator to add pages to clear when a node of that content type is updated. For instance, the site administrator in the given scenario would be able to add the front page to be cleared whenever an image node is updated/removed/deleted.
Comment #8
tim cullen commentedWhew. It's been a while. Sorry I've been a stranger to this discussion. Let me report back a little more about what I learned when attempting further develop and test the code I posted a few months ago.
In a nutshell, it just caused more problems that it solved. The main issue here is that boost (like any static caching solution) allows a site administrator to trade off between performance and dynamic content. In the case of boost views, we found that in even simple use cases it caused unacceptable performance hits in a number of places:
1. By constantly checking for views which have changed (for sites with many views and many nodes this caused real performance degradations in testing);
2. The process of expiring content so aggressively (especially for views which are on blocks which appear on many, if not all, of the sites pages); deleting 30k static files by traversing directories and running the block's regex on each file's derived path;
3. And what follows naturally from #2: forcing the re-creation of static files much more often than boost would normally.
We could never find a sweet spot in our testing. There wasn't really good middle ground between having views stay current and having benefits of a site served primarily from a static cache.
I'd love to hear if other approaches might work for this problem, but it seems to me to be a fundamental issue for a good portion of use cases.
Comment #9
crdant commentedHas anyone made further progress with this module?
I have a slightly different use case, and we're thinking of deriving a solution from Boost to address it. In this case, we're looking at having the static page cache in place for failover only. Since this would be our fourth layer of access -- first is from CDN edge cache, then our primary data center, then our secondary data center, lastly the static cache -- it seems like we have a different equation vis a vis the balance between the performance of regenerating the cache and responding to requests.
I'm still not sure if we'll be able to do it in a fully automated fashion. I'm thinking we might need to @lapith's idea for providing some administrator tools for which cache's to expire.
Comment #10
mikeytown2 commented@crdant
if you can get your sites upgraded Drupal 6, the 6.x version of boost is a better option.
Comment #11
mikeytown2 commentedClosing all 5.x issues; will only reevaluate if someone steps up #454652: Looking for a co-maintainer - 5.x
Reason is 6.x has 10x as many users as 5.x; also last 5.x dev was over a year ago. The 5.x issue queue needs to go.
Comment #12
pmcdougl commentedI know this thread is really old, but I wanted to offer a module suggestion for people who come here from search engines.
Try using the ajax blocks module. This way you can load in your blocks with ajax and preserve some of the dynamic content in a statically cached page.