Donncha O Caoimh (a11n)

And thank you for the reminder. I updated the “tested version” field in the readme.txt so it’s all good.

Yes, it is supported. We just haven’t bumped the tested version number.

@joseribeiro – In the debug log you’ll see messages saying that the cache files are being deleted, and hopefully, it’ll be after some event. That event might be triggered by some plugin you have installed, for example.

also,the preload is taking 5 hours to cache 60 pages! (at least that’s the time between preload start and finish emails I get)

This might be because it’s a development server and nobody is visiting the site to start the WP Cron jobs running. That shouldn’t be a problem with a production site.

Is WP Super Cache completely disabled and not running? Then, the advanced-cache.php was created by WP-Optimize. WP Super Cache wouldn’t delete that file if it doesn’t look like the one created by this plugin. That’s probably why you got that email.

Hi @madflute,

The .gz files are compressed cache files so your cache files are taking up less space.

What you need to do is identify what is visiting your webserver so aggressively.

It’s probably bots, and if it is, you can either ban those user agents or their IP addresses from your server, but that’s beyond the scope of support here, sorry. Or you can stop WP Super Cache from creating cache files for them. They’ll get slower pages but that won’t really matter, except that the load on the server will go up. Look up the “Rejected User Agents” section in the Advanced settings page. Put the useragent you find in your logs there, and the plugin won’t create cache files for them. The useragent is the name of their browser, or the bot name.

It might be worth downloading the contents of the cache directory and checking that each file is the expected size. If you find a file that’s huge, beyond the size of the page it caches, or is being requested directly, maybe there’s a vulnerability on your server and someone is using your server as storage. This is unlikely.

1. Download your webserver access logs.
2. Examine them for what is hitting your site.
3. Look for patterns of aggressive visitors and ban them.
4. Check the files in your cache directory to make sure they’re the proper size. Just in case.

There’s not much else we can do, unfortunately. Sorry.

@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 3 months, 1 week 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 3 months, 1 week 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.