that’s a painful experience ianchin.
some questions/ tips;
* autoptimize is only active on the frontend, you should (have) be(en) able to still log in on the backend and disable AO
* once you’re on the settings-page, you could disable HTML, CSS or JS optimization to see which one is causing this
* the CSS minimizer AO uses is very regex-intensive and as such sometimes crashes violently. as per the FAQ you can switch to the older (less performant) legacy minifier
* minifiers are a jealous bunch, make sure you don’t have any other plugin active that does JS/ CSS or HTML minification
* make sure your Apache (if you’re running that as webserver, that is) has AllowOverrides set to All, else it is possible that the htaccess provided by AO breaks and requests for optimized CSS/ JS result in a HTTP500 error/ internal server error
* your phperror log (if you have that configured) might have valuable information on what went wrong as well
hope some of these prove helpful 😉
frank
Thanks for the quick response! We serve about 200K PVs a day so job #1 was getting the site back up which we did by pulling the plugin. Really should not have played around w/ it in a live environment the way I did. Will review your tips and see if we can’t get it going on our dev server. Thanks again!
ah, 200K pageviews a day … if you have page- or even request-specific (inline) JS (or CSS) then AO will try to re-optimize continuously (as the cache would not contain the already optimized code given the page-specific code) which would indeed generate a huge load (which you would not have seen on DEV anyway).
you can disable aggregation of inline JS/ CSS using the API (see this sticky forum post). The upcoming AO 2.0 will have a option on the settings page to enable/ disable aggregation of inline code.
frank
Hi IanChin;
Have you already had a chance to look further into what was happening here? Anything I could help you with?
frank
