Cache rebuild does not work – nginx preload mode
-
I have the following settings:
nginx (no apache) on http3, custom rules to serve the cached https html files (works)
preload mode running every 10 hours (works)
Expiry Time & Garbage Collection – Scheduler – Timer 600s
Cache rebuild enabled – does _not_ work.
Problem
Upon requesting a URL that is cached on the server (verified, the file exists but was created 600+s ago), wp super cache refuses to serve that file. Rather, it blocks the process, re-renders the page, and serves the newly rendered file. Verified by both changing timestamp on the html cached file, and the html content footer.
Expected
If Cache rebuild is enabled, the static html file must be served and asynchronously regenerate the html file.
-
digging into the code further, @donncha it seems like the bug is due to a call to
wpsc_delete_files( get_supercache_dir() );
This happens after every batch of 10 posts is processed (WPSC_PRELOAD_POST_COUNT), and the preload reschedules itself. However, incorrectly, deletes the root folder after every batch.
Making the matter worse, wp-cron will not fire unless there is a visitor to the side, so the preload process just hangs, waiting for someone to hit the uncached home page – then the preload cron will slow down generating the cachefile, adding extra delay to serving the home index.
This seems a rather big problem in wpsc, not sure how this has never been noticed before 🤔
It’s not as bad as you think it is
It’s actually much worse than you think it is. It is severely bugged, leading to massive spikes in response times. Look at the chart below. This is your bug, refusing to fix, causing spikes up to 4 seconds (!) everywhere around the world.
EDIT: images are bugged out in the post, here is a link to them: https://imgur.com/a/V0s2vCF
And another bug..
I found another bug, terrifyingly. GC runs anyway, regardless of preload mode. This is likely due to setting cache_max_time somewhere to preload mode time.
My settings:
My log:
wp_cron_preload_cache: doing taxonomy preload.
15:57:10 75004 /wp-cron.php?doing_wp_cron=1732895829.8098969459533691406250 wp_cron_preload_cache: no more posts to get. Limit (58) reached.
15:57:10 75004 /wp-cron.php?doing_wp_cron=1732895829.8098969459533691406250 wp_cron_preload_cache: no more posts. scheduling next preload in 600 minutes.
15:57:10 75004 /wp-cron.php?doing_wp_cron=1732895829.8098969459533691406250 wp_cron_preload_cache: clean expired cache files older than 36000 seconds.This is clearly not what the code was intended to do in wp-cache.php:
if ( $cache_max_time > 0 ) { // GC is NOT disabled
wp_cache_debug( "wp_cron_preload_cache: clean expired cache files older than $cache_max_time seconds.", 5 );
wp_cache_phase2_clean_expired( $file_prefix, true ); // force cleanup of old files.
}But in the same file you made a mistake and set cache_max_time to nonzero:
$cache_max_time = (int)$wp_cache_preload_interval * 60; // fool the GC into expiring really old filesI understand you are hesitant to touch these files, contaning over 4k lines each*, but this is so buggy and dysfunctional that I find your position indefensible.
*how did you even get to this point? Methods several pages long, files thousands of lines long. I understand it grew organically, but this is not a hobby project, it’s a for-profit organization.
The fixes you’d need to implement
- Don’t delete home index after every post-batch – the line I mentioned in my previous post can be safely deleted, no reason to wipe out home index after a preload run, it’s clearly a bug
- Don’t set cache_max_time to preload time – the code already caters for disabled GC – it’s also clearly a bug
If in doubt, again, please do look at the chart above – your cache plugin causing massive spikes, despite every setting on the plugin indicating this would never happen.
The topic ‘Cache rebuild does not work – nginx preload mode’ is closed to new replies.
