wp-media
Disable Preloading on Kinsta
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?
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.
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.
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.
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.
@wp-media/wprocketplugin I ping you here to include all devs into the discussion.
@hellofromtonya If you have any thoughts / feedbacks.
A possible enhancement is to set a case for hosting services were we don't manage the cache to limit is_already_cached() to check if our signature is present on the DOM.
<!-- This website is like a Rocket, isn't it? Performance optimized by WP Rocket. Learn more: https://wp-rocket.me -->
Or a hosting-specific check by looking for the value of their cache headers.
For example for Kinsta, if x-kinsta-cache returns a HIT, we set the result of is_already_cached() as true to bail out of the preload for the specific item.
https://github.com/wp-media/wp-rocket/blob/aea8f96b0725f900deaa337af2f87c37277676ff/inc/Engine/Preload/AbstractProcess.php#L221-L245
Howdy!
I'd like to revive this thread.
On WP Cloud hosts like Pressable, WordPress.com, Bluehost, Newspack, and more -- caching is provided out of the box and is currently handled via batcache on top of memcached.
WP Rocket's cache isn't used. WP Rocket's team has worked on compatibility for this in the past, disabling some of the caching options on Pressable and WordPress.com.
We're observing WP Rocket Preloader requests when Preload Cache is enabled that don't seem to be doing anything much other than causing self-DoS situations.
We'd like to look into a filter for disabling the Preload Cache option or to have it disabled if our platform variables are detected.
Hello @JoshuaGoode thanks for your comment.
We're observing WP Rocket Preloader requests when Preload Cache is enabled that don't seem to be doing anything much other than causing self-DoS situation
It should still generate the warm up the cache, even if server-side caching mechanism is used, right?
Feel free to reach me at piotr[at]wp-media.me to talk about compatibilities between WP Rocket and specific hosting environments.
In 3.16.2 we're introducing improved and more intelligent preload. Please be in touch with me using the provided email if we'd still want to implement this one