Greetings. I encountered a problem when using boost on a site with a large number of taxonomy terms, on which most content was displayed via a series of views. Occasionally when updating nodes, db_query() was reaching the PHP execution timeout for my site (120 seconds). After much wailing and gnashing of teeth, I eventually realized that boost was attempting to expire every possible page view which contained the node I was editing, including all possible combinations of taxonomy term arguments, which in some cases was over 100,000 distinct pages. This is more than preg_replace_callback() can process in two minutes, and so the edit failed, resulting in empty strings being inserted into the node_revisions table and the content seeming to disappear on my beleaguered editors. See the attached screenshot of a stack trace with more details.

Clearly the solution here is to tell boost not to bother expiring views pages on node update, and instead just live with those pages showing the old content until they expire (in my case, 15 minutes). I've now done this, but for the sake of the next person with this problem, I propose two changes: first, a reminder in README.txt about the consequences of expiring large numbers of views pages would have helped me track this down much sooner. Secondly, for people who don't proactively read the documentation, it would be reasonable for boost_cache_kill() to do a sanity check and refuse to expire more than, say 1,000 pages at a time.

I propose something like this:

define('BOOST_EXPIRE_LIMIT',         variable_get('boost_expire_limit', 1000));

And in boost_cache_kill():

// Sanity check -- don't try to expire more than BOOST_EXPIRE_LIMIT pages at once
$files = array_slice($files, 0, BOOST_EXPIRE_LIMIT);
CommentFileSizeAuthor
#1 Image 2.png132.55 KBmvc
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mvc’s picture

FileSize
132.55 KB

Screenshot attached.

mvc’s picture

Priority: Normal » Critical

Hmm, something else is wrong. I see in my debugging traces that boost is still trying to expire 10k+ views pages even when configured to ignore all views. I have also come to doubt that so many views pages could have entered the cache within the 15 minutes prior to me editing the node in question, googlebot notwithstanding, so I suspect there is a more serious problem here. Given that this causes a WSOD and has the effect of wiping out the content of a node when doing a minor edit I'm going to raise this to "critical".

This bug only came up approximately one out of 50 times I edited a node, so I'm not sure how to proceed with debugging it, but I wanted to at least post a problem description in case anyone else notices this problem.

mikeytown2’s picture

Try the latest dev; it has better debugging info

mvc’s picture

@mikeytown2: It would be hard for me to try the latest dev. It took me a week to track down and reproduce this error, and I was never able to do it on my staging site. The only way to reproduce this is to turn on expiration of views pages and then sit back and wait a day or two for my client's production site to break, which as I'm sure you can understand I'm not very interested in doing.

Also, I take back the part about boost not honouring the "ignore all views" setting. Now that I've turned that off, I see no errors at all. But I'm still convinced there's a serious problem somewhere here.

I created a detailed debugging trace while investigating the problem which is hopefully self-explanatory. It's over 1M so I've uploaded it elsewhere. Here's a link: http://www.sciencepresse.qc.ca/boost_error_log.txt.gz