Wp-rocket: Disable Preloading on Kinsta

[alfonso100]

We have received a message from Brian Jackson, Kinsta's CMO:
https://secure.helpscout.net/conversation/904419725/116191?folderId=343175

Improving Kinsta Integration and Performance

Our sysadmins have let me know that our clients have been having some issues with the WP Rocket preload CRON job and it actually crashing some sites at Kinsta.
I'm not sure if this is because it's CRON job for cache that technically doesn't exist, since caching is disabled on our platform with WP Rocket. (I don't know all of the technical details, but can get them)
We are curious if it's possible to just disable preloading at Kinsta automatically since it won't be used anyways.

Since our page caching is disabled on Kinsta server, should we disable Preload?

[Tabrisrp]

Our preloading should still be preloading the NGINX Cache used by Kinsta, so there is still value for it.

Disabling the feature all together requires to think about how to display that in the settings, messaging to the users, etc.

[arunbasillal]

I am in touch with Kinsta to figure out more details of this issue and then we can come up with a more optimal solution rather than disabling the entire feature.

[brianleejackson]

Yes, are issues are continuing to increase. I've dug into this a little more with our sysadmin team and the main problem is that our caching by default expires every hour on our platform. So preloading essentially, in this case, is running almost all the time and doesn't make sense. That's especially true if it takes a while to build up the cache again.

We increase the cache for some customers, even up to months if they ask. But by default, our platform cache expires every hour. Therefore a large majority of our clients are running this way. So preloading in an environment where cache expires every hour as you can probably gather is not very efficient. Hopefully, that helps you understand the issue a little more.

It would be great to disable the feature perhaps entirely, but have a hook/filter that could be used to enable it? This way it wouldn't cause any problems in our environment and then on those clients that have increased the expiration cache time, the preloading does make logical sense. And we could have the hook/filter documented on our side in a KB for those clients, as well as our support engineers.

[danielpataki]

Hi Everyone,

Thanks for taking the time to work on a good integration between the two systems, it is much appreciated!

My stance on this relies very much on exactly how your preloading works. The issue I have is that preloading can essentially act like DOS attack, since you may be using considerable server resources for not a whole lot of gain.

On our end since our cache is cleared every hour there are two situations:

• Either preloading is "greedy" and starts preloading as fast as it can
• Or preloading is "lazy" and preloads slowly

If preloading happens rapidly it will essentially negate the benefits that caching produces. If it preloads slowly, then there is a slim chance it will have preloaded the specific page the user happens to visit.

I would be strongly for disabling preloading completely. We would eventually like to increase our cache busting time at which point we could discuss this further. We may also want to talk about preloading some key pages, like the home page for example.

Those are my initial thoughts and they are dictated by no deep understanding of how preloading works on your end so correct me if I'm wrong or if I'm misunderstanding something.

[GeekPress]

@wp-media/wprocketplugin I ping you here to include all devs into the discussion.

@hellofromtonya If you have any thoughts / feedbacks.

[Tabrisrp]

Can be part of our preload rework for 3.7