i'm using boost along with apache solr faceted searching and i've run into problems where the huge number of possible URLs created by combining facets has made boost time out when trying to expire old pages. so, i'm using drush to forcibly clear the cache from time to time. this is all fine except that 'drush boost-reset' is also clearing boost_cache_settings, which seems wrong to me.

patch attached.

CommentFileSizeAuthor
boost-cache-settings-table.patch1.9 KBmvc

Comments

j0nathan’s picture

j0nathan commented

Same issue, subscribing.

romanellom’s picture

romanellom commented

the problem is still present

mvc’s picture

mvc
they
Primary language English
Location Montréal, CA
commented

@romanellom: can you please test my patch and mark this as RTBC if it works for you, or let me know what's wrong if it doesn't?

bgm’s picture

bgm commented
Status: Needs review » Needs work

Approximately how long does it take for mysql to truncate your boost_cache_settings table?

(to run the command from the mysql command line, for example)

When will this table be emptied otherwise? Big tables cause performance issues with MySQL (on insert/select), so can't let it grow forever.

digi24’s picture

digi24 commented

bgm, the description in the first post is a bit misleading, it is not about database performance, but about clearing a table too much.

I agree with the patch, clearing the settings table does not make sense, it works fine for me (have not tested the drush part).

bgm’s picture

bgm commented

You're not answering the question though. Since this can potentially affect 10k sites using 6.x-1.x, I'm rather conservative on changing these type of things.

I'll get back to this after the 6.x-1.19 release (imminent, please test if you aren't already using that or 6.x-1.x-dev), since there have already been too many major changes since 6.x-1.18.

mvc’s picture

mvc
they
Primary language English
Location Montréal, CA
commented

bgm, what we're trying to say is that this is user-entered, configuration-level data. this table does *not* contain the cache itself.

it doesn't take very long to truncate the boost_cache_settings table; this only contains configuration information (a manually-entered list of pages with special boost caching rules).

this table would normally only be emptied when a user manually deleted every single manually-entered exception to the default boost caching rules.

does that help?

bgm’s picture

bgm commented
Version: 6.x-1.x-dev » 6.x-1.20
Status: Needs work » Fixed

@ mvc: perfect, thanks for clarifying!

Committed to 6.x-1.x, will be in boost 6.x-1.21. (trying to figure out how to use these versions on d.o so that release notes are easier to write)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.