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.
Comment | File | Size | Author |
---|---|---|---|
#4 | boost-621148.patch | 1.75 KB | mikeytown2 |
Comments
Comment #1
mikeytown2 CreditAttribution: mikeytown2 commentedSee 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...
Comment #2
mikeytown2 CreditAttribution: mikeytown2 commentedCache 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.
Comment #3
mikeytown2 CreditAttribution: mikeytown2 commentedComment #4
mikeytown2 CreditAttribution: mikeytown2 commentedShould Ping database every 59 seconds
Comment #5
EvanDonovan CreditAttribution: EvanDonovan commentedI 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.
Comment #6
mikeytown2 CreditAttribution: mikeytown2 commentedyou 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?
Comment #7
mikeytown2 CreditAttribution: mikeytown2 commentedcommitted
Comment #8
EvanDonovan CreditAttribution: EvanDonovan commented@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!
Comment #9
mikeytown2 CreditAttribution: mikeytown2 commented@EvanDonovan
Write the guide here or put a link to it here
http://drupal.org/node/583264
Comment #10
EvanDonovan CreditAttribution: EvanDonovan commentedThanks for the link. I'll add that when I get a chance.