Have you reviewed the “error_log” for the website? While there may not be errors presented on the website itself, it’s possible PHP is correcting them internally which can cause extra load.
Yes, I understand, but why. I really don’t understand. It says everywhere that I need to have a cache plugin. I believe you, I just want to know why it’s a problem.
Is it also good to use caching on the server itself? About OPcache?
You should try to address, or work with the vendors (of any plugins) to address errors. These errors may seem insignificant, however everytime PHP has to correct an error during run time it utilizes more resources then if there were no errors being produced. The goal is to eliminate errors.
You cache a regular static website that doesn’t change so that it doesn’t have to load the same page / images all the time.
YOU DO NOT want that on an ecommerce site because customers can (and do on pages that use it) see one price on their screen but a totally different price or product in the cart. That is why you never us it on an ecommerce page.
Caching plugins are fine on ecommerce stores, as long as both the ecommerce app and the caching app are written using reasonable best practices and using standard WordPress APIs for interacting with data. But, disabling caching won’t help with OPs problem. If they aren’t seeing problems with caching (i.e. serving out old data in the store), there is no reason to go nuts about them using a caching plugin.
I want to point out that the high CPU usage is not Virtualmin…so, your title is asking about the wrong thing.
WordPress is using a lot of CPU. Your database is using a pretty good chunk of CPU. So, that’s what you need to troubleshoot.
I would recommend you read up on tuning MySQL/Mariadb for WordPress (but don’t do anything extreme, like cranking up values multiple times higher than current…that can make things much worse). Also, when it comes to limiting things like number of PHP FPM processes, it is usually better to lower those limits than increase them, as lock contention can be more damaging to CPU usage than having those requests queued briefly by the web server while fewer PHP processes serve the request.
You may also need to turn on slow query logging in your database to see if any queries are taking a long time. That usually exhibits in other ways (slow responses from the site without any apparent heavy CPU usage from PHP), but it never hurts to have your apps able to get answers from the database fast, and ecommerce apps often have wildly complicated queries. It may help to add indexes to some of those tables (if they don’t already have them), and/or tune your app to use the database less aggressively (maybe turning off plugins and features that hit the database if you don’t need theme).
And, you may just need more resources. WordPress and WooCommerce are not particularly efficient. They’re good at what they do, but they are large and resource hungry.
I have personally seen the plugin W3 Caching rack up memory issues on top of SQL request issues. I’ve also seen them overhold images to where someone views a product one day, comes back a week later and sees the same product when in truth it is no longer on the site.
But hey, don’t take my word for it. Woocommerce says the same thing.
1. Don’t Cache WooCommerce Pages
2. Don’t Cache WooCommerce Sessions
3. Don’t Cache WooCommerce Cookies
The problem is, the VAST majority of run-of-the-mill caching programs do ALL of that. And it screws up a whole lot.