*Many* cachebuster requests

Same problem here. As a web hosting provider, we have had to reach out to customers to disable or delete the Autoptimize plugin, as version 2.3.1 changed something to cause extremely high resource usage. We are seeing 10-15 requests PER SECOND, just like the above reporter shows… the script itself requesting all these cachebuster URLs. The websites are eating themselves alive.

– Scott

• This reply was modified 7 years, 2 months ago by sneader.

somewhat flabbergasted I’m afraid (although I’ve heard this once or twice before); the cachebuster-calls are exectuted ONLY when AO’s cache gets cleared to auto-populate the cache again (cfr. the relevant code here). As AO _never_ purges it’s own cache, the cache _only_ gets purged when the user clicks “save changes & empty cache” on AO’s settings page OR when another plugin calls AO’s public autoptimizeCache::clearall function.

now the first (clicking “save & empty cache”) is _very_ unlikely to be causing this, so we have to assume we’ve got some other plugin (no idea which one I’m afraid) clearing AO’s cache way too frequently.

the (only) good news here; you can stop the cache from being auto-populated by adding this filter;

add_filter('autoptimize_filter_speedupper', '__return_false');

hope this helps,
frank

identical problem here on several sites on dedicated server.
Load goes up, and available memory 1%

same explanation as above @rvola, use the code snippet to disable preloading of AO’s cache and all should be fine.

@rvola, @sneader, @uk06 I’ve given this some more thought; even if due to another plugin calling the public function it’s still AO causing the overload, so I’ll look into adding something to stop this from happening more then once per hour.

Hi guys;
I just pushed a commit to Github that should prevent this from happening, can you test this by either making the change in wp-content/plugins/autoptimize/classes/autoptimizeCache.php as per the commit or by downloading the zip-file from Github and installing that over the current version?

frank

possible root cause (which an AO contributor provided me with); if an object cache (redis or memcached or similar) is used, it is possible that the Autoptimize version does not get updated, causing the autoptimizeCodeUpdate logic to keep on running again and again (as code version is and remains different from version in the database as fetched through WordPress get_option()), flushing the cache and execting the warmCache/ cachebuster call to preload the cache.

this is something that cannot be fixed in Autoptimize, as it’s related to the way options are handled/ stored in WordPress core, but an easy fix would obviously be to flush the object cache.

so @rvola, @sneader, @uk06 are you using an object cache (redis, memcached, …)?

Would flushing the cache just be a temporary fix, though?

thanks for chiming in @dylanwpe!

the basic problem as we understand it now a problem of stale object cache:
1. autoptimize compares its own version in the code with the version retrieved from the database using get_option(‘autoptimize_version’).
2. due to an issue in core it is possible that an external object cache (redis, memcached, apc, …) has a stale version of that data (in the alloptions cache key)
3. in that case get_option('autoptimize_version') would return 2.2.0 from the object cache (alloptions) instead of 2.3.0 from the options-table
4. this then triggers AO’s update routine, which includes emptying the cache and then trying to preload with the “cachebuster”-request.

the fix which I now included in the Github-version stops the preloading from happening too frequently, but the update-routine including the cache purging would still executed.

now for your question: flushing the object cache is a temporary fix yes, but it is effectively the only way to ensure that Autoptimize sees the correct version-string, as AO can only assume the value returned by get_option to be correct. the only “root cause fix” seems to be described in the WordPress Core bug report and have been under discussoin for years already :-/

Hello !

Yes indeed use of Redis.
However I have to purge Redis after the update “redis-cli flushall”

yet the server goes into the wall

@rvola; can you check the output of get_option(‘autoptimize_version’) ? is it “2.2.0” or “2.3.0”?

The issue does seem to be with a persistent object cache. I’m also using Redis for object caching, and my server hit the iceberg the moment I updated Autoptimize. CPU and memory usage spiked to 100% and MariaDB crashed, resulting in database connection errors, effectively taking down all websites being hosted on that server, be it under any user account. (I manage my own VPS with a bunch of sites on it, all running under their own user accounts.)

To isolate the problem, I disabled all other plugins on a site, keeping only my two cache-related plugins (Nginx Helper that I use to manage my nginx fastcgi cache for full page caching, and Redis Cache for my object cache) enabled. Updating resulted in the exact same spike, crashing MariaDB after a major CPU and RAM spike, effectively bringing down all websites on the server.

I then deleted autoptimize via FTP, restarted MariaDB, restored the last good backup and repeated the above steps, but this time, I cleared the fastcgi full page cache and disabled Nginx Helper before updating Autoptimize. The issue persisted.

I repeated the above again, this time leaving Nginx Helper enabled, clearing object cache and then disabling it in the Redis Cache plugin. Viola – no CPU or RAM spikes, no MariaDB crashes, no sites down!

To test further, I enabled the Redis Cache plugin, and within the next ten seconds, MariaDB was down, taking all the sites down with it as before.

To confirm if it was being caused by some conflict in the object cache, I reverted everything back to the last good backup, cleared Redis cache followed by disabling it in the Redis Cache plugin, cleared Redis cache from the CLI, stopped the Redis service itself, updated Autoptimize, restarted Redis service, cleared its cache again from CLI, then enabled object cache in the Redis Cache plugin and immediately cleared its cache again from the plugin. This time, the issue didn’t return.

I hope this information helps with a permanent fix, because the way I understand it, the current fix is more of a quick fix to make sure the server doesn’t go down upon upgrade, but doesn’t really fix the problem at its root.

Not using Redis or memcache here. The only thing I can think of is that we have PHP’s built-in opcache module enabled. Could that be it?

@sneader I don’t think it should be opcache as that only caches the opcode generated from PHP so that it doesn’t have to be regenerated on each page load unless the code has changed. This seems to have more to do with a persistent object cache of some sort. It’s Redis in case of some (including me), while Memcache/Memcached in case of others. Are you using any other method for your object cache?

Also, if you aren’t using a separate object caching solution, I think WordPress directly stores transients somewhere (disk? memory?) by itself as well (and I’m not an expert on transients so anyone who reads this part and knows more about them than me is more than welcome to correct me if I’m wrong). Could perhaps be because of that, and clearing those transients before the update might help?

In this scenario, I’m thinking you’d want to clear Autoptimize cache, then disable it, then clear transients, then update Autoptimize, then enable it and clear its cache again for good measure as soon as you enable it. (Again, no expert on transients, so I might be totally off here, but it’s worth a try and should be perfectly safe.) As for clearing transients directly, I’m sure there must be multiple plugins out there that should allow that.

Hope it helps. Do let us all know how it goes.

• This reply was modified 7 years, 2 months ago by Haroon Q. Raja.

Great feedback @hqraja, thanks mate!