Donncha O Caoimh (a11n)

@joseribeiro “preload mode” is supposed to stop garbage collection from running, or at least, from deleting any files.

The next thing I would do is enable the email feature in garbage collection. That will email you when it runs so you can check if it deletes any files.

Since your site hasn’t launched yet, you could enable debug mode. Go to the Debug tab and enable it there. The logs should show you when cached files are deleted. There is a small chance the debug log viewer script is deleted by the garbage collection too, due to a small bug, but you can download the log file itself from the cache folder to your computer to look at it in a text editor.

I think your site is getting hit by a lot of bots, and they might not be checking if the page is really different. The “last modified” time on a blog post isn’t the published time because widgets in the sidebar or content elsewhere on the page might have updated.

Also, 6GB isn’t a whole lot when you look at the size of the page. The most recent review on the site is 217Kb. 28 such reviews will take up 6,144Kb if they’re all cached. There’s more than 28 reviews. If you can make the page smaller, that will help.

On the Advanced settings page, did you enable compression? That will make the pages smaller, but if it’s bots hitting your site that don’t support compression, then the pages won’t be stored compressed.

Regardless of solution, also want input on why content-type was served as application/x-gzip. Can’t see how CloudFlare would affect exactly that.

This plugin sets the content-encoding to gzip here, so maybe something else on your server is setting the content-type. However, about 15 years ago something similar was reported and I added extra checks on the homepage. There’s a check for x-gzip here because of it. I could never figure out what caused the problem.

• This reply was modified 2 months, 4 weeks ago by Donncha O Caoimh (a11n).

BTW, further updates will be on the GitHub issue, so you can follow that. I’ll mark this issue resolved.

Could you make sure that “WPCACHEHOME” is defined in your wp-config.php please? Do you have any process that updates the wp-config.php on a regular basis?

The advanced-cache.php file that the plugin is recreating is created in wp-content/ and if it’s being deleted by something on your system it needs to be recreated, and it shows this warning. Maybe you have a security system that deletes “unknown” files?

Unfortunately, we don’t have any Windows machines running IIS to test the plugin on as it’s so uncommon, compared to Unix servers, so we can’t offer any advice WRT server settings that might help.

• This reply was modified 2 months, 4 weeks ago by Donncha O Caoimh (a11n).

Thanks, @adamh007 for the detailed reply. We will look into those issues, and get back to you.

https://github.com/Automattic/jetpack/issues/40411

@squire2k anything?

It’s not as bad as you think it is, but when it was first implemented, the preload system handled 100 pages at a time, rather than 10. 10 was picked during the last update because some sites on very low powered hosting had problems. (In hindsight, they should have upgraded their hosting, as their server could barely cope with a 2 pages loading in parallel. They eventually did upgrade.)

Set WPSC_PRELOAD_POST_COUNT to your own limit, and the homepage won’t be deleted so often.

WP Cron operates async, with a request to wp-cron.php to run the preload, so the front page of your site will be served uncached as quickly as it ever will be.

If you want, you can disable WP Cron by setting “DISABLE_WP_CRON” and running it from the system cron. That may be more reliable if you have a low traffic website.

Preload could be improved. It’s not perfect, but we don’t have plans to change it in the near future.

The “cache rebuild” feature probably should have a “learn more” link next to it because it’s a complicated feature.

I’m wondering, under what circumstances is it better not to serve a stale file when I asked to “Serve a supercache […] while a new file is being generated”?

When the cached page is considered stale and normal operations of the plugin have caused the cache file to be expired. It’s presumed that your server will generate a new page quickly. On the other hand, if the page has been invalidated by someone leaving a comment, for example, it shows external activity on the site, and there might be more pressure on the server to handle a large amount of incoming traffic. In those cases, the rebuild feature really helps to reduce the server load.

There’s no right or wrong way about this, as there are good arguments on both sides.

Alternatively, what’s the point of async pregen every x hours if the cache timeout is less than x hours and all of the pregen files would be thrown away?

You can enable “preload mode” which disables garbage collection. Otherwise, it’s up to you to set the garbage collection times according to how fresh you want your cached files.

I’m hoping you can see the two timeouts and the checkbox creating a very non-intuitive situation, where the server is not serving cached files, even though I asked it to do so, and I even run a periodic pregen process.

Bots and other visitors to your site will regenerate the cache files too. There are other plugins that create a static copy of your site, which might be what you want, but the aim of this plugin is to speed up popular pages so that most of the visitors hitting them get a cached copy. The first visitor might get a fresh copy, but it shouldn’t be too much slower if the rest of the site is cached and the server is doing little.

Yes, the garbage collection settings could be laid out better. If you have ideas or a patch to contribute, you can add it to the Jetpack repo at https://github.com/Automattic/jetpack/, and make sure to specify the “Super Cache” plugin.

Yes, there is. Look at the Advanced settings page for the “Rejected URL Strings” section where you can enter some strings from the posts in that category, I think if you add “/reviews/” without the quotes there, it should stop those posts caching.

That might cause the webserver to run more slowly though, as there is someone online hitting those pages for some reason.

Unfortunately, without access to your server, I can’t say for sure why that’s happening. It may be a misbehaving plugin that’s making extra queries to your site, I don’t know, sorry.

WP Super Cache is definitely making an impact on how well your site runs. The first time I looked at that page, there was a noticeable lag while it loaded, but when it was cached, it loaded very fast.

This patch should resolve the problem. It’s not enough to check if it’s false once because if the data is gzipped before that, it will no longer be false.

Thanks @keepmovingdk for the patch. I’ll add that, but the readme.txt has warned about using an NFS share for the cache directory for a long time. It’s safer to use something like Batcache if you have multiple web servers.

Hi @adamh007.

Have you enabled debugging in the plugin and checked what the plugin says it’s doing when it’s serving a page that should be cached? If a file is older than the cache timer of 600 seconds (in your case), it won’t be served. It’s too old and considered obsolete.

Cache rebuild is for when a cache file was supposed to deleted by an operation like leaving a comment on a page, but instead, the next visitor gets the previous cache page, while WordPress creates the new cache file.

Donncha

Since you have WP Control installed, and you can see wp_cache_gc show up there in “Cron Events”, set the GC Timer to 60 seconds and keep reloading the WP Control cron events pages to see if wp_cache_gc triggers. Is it scheduled again afterwards?

I suspect some other plugin updated and is causing problems. You might also check your PHP error logs. If another plugin is causing a fatal error when it runs a Cron job, it might be stopping the garbage collection from running. You could also disable other plugins one-by-one, and then go to WP Control and click on “run now” under the wp_cache_gc job. That might help track down the problem.

You might need to contact your hosting support to get this fixed. Someone with access to your site will probably be able to fix this quickly.