When I try to save admin/settings/performance, I consistently get a MySQL has gone away error, followed by a series of other errors. However, other pages on my site continue to load, so it is clear that the database is still up. I just realized today that I think what is happening is that Boost is doing a recursive rm of its cache directories when I save the admin/settings/performance page, which causes there to be a long time where the database is not being accessed. This causes MySQL to go into wait, and ultimately to hit the timeout, which on my site is set to 120 seconds.

I am wondering 1) whether I am correct in my analysis, and 2) if there is a way to work around this. I would like to save the performance page without it hanging & hitting an error every time. Note that when I reload the page, I can see that the Boost cache has been successfully cleared.

CommentFileSizeAuthor
#4 boost-621148.patch1.75 KBmikeytown2
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mikeytown2’s picture

See if this patch and db updated does it
#620636: On large node counts, boost_has_site_changed() can be very slow

Oh nm, I should have looked at the version number...

mikeytown2’s picture

Cache CSS & JS files and then set "Ignore cache flushing:" to "Only Ignore Clear Entire Cache Commands" under Boost advanced settings.

Due to how Drupal operates the cache has to be flushed when the save button is pressed on the admin/settings/performance page. Otherwise you get missing JS/CSS files.

I will see if I can "ping" the database so one doesn't get the "MySQL has gone away" error when doing that operation. Do it every 60 seconds or something like that.

mikeytown2’s picture

Title: "MySQL has gone away" error when saving admin/settings/performance - recursive rm of Boost cache causing MySQL wait? » "MySQL has gone away" error. Long running recursive rm of Boost flush cache causing MySQL connection to time out.
mikeytown2’s picture

Status: Active » Needs review
FileSize
1.75 KB

Should Ping database every 59 seconds

EvanDonovan’s picture

I will try to upgrade my Boost install soon. I have trouble keeping up with the upgrades because they are so frequent (that's a good thing).

I don't like to upgrade too often because I am concerned of what would happen if it stopped working. Also, I have several hacks to get Boost to work with the various theme-switching modules I have enabled. But it sounds like I should go up to the most current release soon and then apply the "DB ping" patch you just made, which seems like it should work.

I am hoping I can figure out how to get the JS/CSS caching to work with Lighty soon, because I can't follow your advice in the first paragraph of comment #2 until I do that.

mikeytown2’s picture

you should be able to extract the code from the patch and create your own, let me know that the idea works.

Any chance of contributing back your theme-switching code?

mikeytown2’s picture

Status: Needs review » Fixed

committed

EvanDonovan’s picture

@mikeytown2: The theme-switching code is integration with a few different modules, primarily one that's no longer available on D.O called Referertools. I don't think it would be relevant to the module, since it's such a specific use case. But I could post an issue outlining the overall technique. It required adjustment of Boost's is_page_cacheable() function, the Boost .htaccess rules, and the other module (so it would set a cookie that Boost could test for).

I will go ahead then & roll my own "ping DB" patch based on your code. Thanks!

mikeytown2’s picture

@EvanDonovan
Write the guide here or put a link to it here
http://drupal.org/node/583264

EvanDonovan’s picture

Thanks for the link. I'll add that when I get a chance.

Status: Fixed » Closed (fixed)

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