Last month, we updated our website with you last plugins and addons. We ever since noticed huge php-fpm cpu consumption raise (twice what it used to be).
Query monitor shows in most admin requests a big load from WPML plugins, especially String translation.
I needed to build only the system files through duplicator (too big db).
I put both system files and the db in a zip archive.
How do I share this archive link *privately* with you?
If you need to send us a Duplicator package or archive of your site, please use a file sharing servicer like WeTransfer and use the private area I am opening to send us a downloadable link for this.
I have consulted with our 2nd tier support. For performance issues, please follow these suggestions:
TIPS
1. Lower the weight of the page size in MB. Compress images (EWWW plugin), minimize their quantity.
2. Try to check your site with faster internet connection.
3. Deactivate all unneeded plugins. Do not use monitoring plugins like a Query Monitor on production site.
4. Try to implement object caching with Redis. This significantly improves performance on backend. It requires support on hosting or VPS and a plugin. Better use this one: https://wordpress.org/plugins/redis-cache/ Some page caching plugins like a W3 Total Cache can provide object caching too. In this case, Redis Cache plugin is not needed.
5. Try to use faster hosting or VPS server. Heavy sites require more resources.
6. Try to use page caching plugin like Super Cache, W3 Total Cache, or WP-Rocket.
7. Do not use any kind of SSL-helping plugins. They produce significant overhead redirecting every request. To use https properly, just convert all links in the database by Duplicator plugin or WP-CLI.
After doing this, then test performance as follows :
HOW TO TEST PROPERLY
1. Try to turn off plugins one by one and make sure that issue is related to WPML plugins.
2. Try to switch theme to standard to make sure that problem is not related to the theme (as it was with Jupiter)
3. Make sure that impact of WPML is more than +30% to the page loading time. WPML provides a lot of services, and they cannot go without a cost – some resources are needed: (processor, memory, db requests)
4. Please use the simple Chrome extension Page Load Time (hidden link) to measure loading time. It weights nothing in contrast to Query Monitor.
5. Cache plugins should be turned off to understand the impact of WPML or other plugin/themes
Note : HOW TO *NOT* TEST
1. Do not use Query Monitor on production site. With WPML, it slows down a site significantly. QM should be used to see what is going on, then switched off.
2. Do not rely fully on QM results. It is very powerful tool, but problem is quite often not in database requests, which take a small amount of overall time. It is better to use xhprof (some hosting providers give the opportunity to use it), or Blackfire (on VPS)
I believe these suggestions from your second tier support team, are generic.
May I ask if you took time to deploy the Duplicator archive I provided?
If so, you probably noticed that our website fits all the upper suggestions.
With regards to the test process, I already went through it when I reached the support chat in the first place. The support mate asked me to provide you with a duplication of our website, because he found the amount of requests initiated by WPML, and especially the string translation module, as shown by QM, was surprizingly high (I provided some screenshot of QM results).
Since I needed time to go through the duplication process, We turned that chat into a ticket.
Nonetheless, I'll answer each of the points you enumerated here. So that we're on the same page from now on.
1. Lower the weight of the page size in MB. Compress images (EWWW plugin), minimize their quantity.
>> This occured right after updating our website's plugins. Therefore, pages weight remained the same it used to be before this update.
By the way, we do take advantage of an image compressor, for years now (ShortPixel not to name it).
2. Try to check your site with faster internet connection.
>> We did. The problem is not bandwidth related, but appearsto be a resources consumption issue instead. The sites get extremly slow when we overcome the resources allowed by our hosting provider, for a short period of time (burst). This never occurered since mid-2018 when this website went live.
Finally, it's not a trafic related issue either, since this also occurs on a dev environment, also submitted to the same burst rules, but where no external trafic is allowed.
3. Deactivate all unneeded plugins. Do not use monitoring plugins like a Query Monitor on production site.
>> We already did (explained in point 1).
4. Try to implement object caching with Redis. This significantly improves performance on backend. It requires support on hosting or VPS and a plugin. Better use this one: https://wordpress.org/plugins/redis-cache/ Some page caching plugins like a W3 Total Cache can provide object caching too. In this case, Redis Cache plugin is not needed.
>> We use memcached for ages now, BUT not for wp-admin/ requests. It's always been this way though, and it's never been a problem before. At multiple times, our setup went through both high trafic load (TV reports) with no issue, and intensive admin pages usage (without page cache then) during which we never notice such slowdowns. Therefore, the performance issue we relate here is probably not related to an object cache failure.
5. Try to use faster hosting or VPS server. Heavy sites require more resources.
>> Our site is deployed on a powerfull instance. 4cpus, 16 GB). The website is not heavier than it used to be before this plugins update (no posts/pages/products added), unless some plugins made it more resources-needing. Now, the most consuming plugins are... WPML's. Finally, WPML plugins still look very resource-consuming when they remain the only ones active. That's why I'm looking for help here.
Please take a look to the resources screenshot enclosed. The step you'll notice corresponds to the plugins update deployment and the peaks appearing after that step, way above 20%, to admin page usage.
6. Try to use page caching plugin like Super Cache, W3 Total Cache, or WP-Rocket.
>> We use W3TC since 2018, and already checked we didn't move any parameters.
7. Do not use any kind of SSL-helping plugins. They produce significant overhead redirecting every request. To use https properly, just convert all links in the database by Duplicator plugin or WP-CLI.
>> We don't use such plugins.
Since we follow all these precautions and took time to test our website, didn'tanalysis may I ask yuo to take a closer look at the Duplicator archive I provided you with?
I am Sumit from 2nd tier support. Yvette for a few days so I will handle this ticket. I hope it is fine.
I checked the login details but the site seems to be hosted on the local server or the domain name is not valid. Please see [linked removed]
If we need to set up the domain name in the hosts file then please let us know the IP address of the site or please provide the site details which we can access. I am enabling the private reply again.
Also, please let me know a page link or action you perform and find slowness.
Can you please hide the previous message, since our company name appears?
Indeed, I provided you with a local copy of the website, which is under git repository. It's in the very same state as the production one, unelss it doens't includes customers the personal data.
Can't you work with that?
If really needed, I can provide you with a production database.
Thanks for the feedback! I have removed the link from the previous message.
I can deploy the package but our server may be slow or fast as compared to your server so it will be difficult to find out whether the site is slow or fast. That's why I asked for the staging site on the same server so we can check the website on the same server where the production site is running.
Anyway, if this is not possible I will try to test this on our server or local server. But what should I test? please elaborate a bit more on where do you see the slowness? A page link or action you are performing.
The problem occurs on our server when the CPU load has too high over a specific (short) period of time. It's kind of burst: if we exceeded a volume of CPU consumption over a period of time, won't be allowed to use more than 20% of CPU, and some request take ages, or basically generate 504 errors. Thats what occurs on our AWS Lighsail instances, only since november's plugins update.
By the way, I'm currently doing some testings on a test env., disabling slightly all plugins, watch resources consumption...
That's a real pain, but I found something interesting.
When most of our significant plugins are inactive, W3TC and Autoptimize disabled, and without front trafic (this instance is not public), the CPU consomption is almost null.
On the other hand, I figured that multiplying the amount of open admin pages ask for more resources, even if no actions occur on these pages.
And that's much, much more significant with (almost) only WPML and WooCommerce active.
Now , if I watch the network, from my browser, I figure there are 2 kinds of requests :
- jquery requests, especially for heatbeat calls
- admin-ajax.php calls a WPML js script : /wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/tm/dist/js/ate-jobs-sync/app.js, which makes muuuuultiple requests, every 10 seconds, from every single open admin page.
Script: apps.js / hidden link Initiator:lines 83, 6 and 69 / hidden link
Last but not least: this occurs:
- on our production environment (WPML 4.4.10)
- on our preproduction,
- on an similar test local env., with the same plugins versions that the production and preproduction
- NOT on the same local env, with our plugins at the state before the suspected update (WPML 4.5.0). Here, no WPML script requests
As soon as I disable WPML plugins, the resources consumption drops significantly, even with many admin page relaoded (but where these WPML request don't appear anymore from the network view).
I activated only WPML + Translation strings, and reloaded 8 admin pages (it takes ages): CPU load: 40%.
Then, I deactivated WPML + Translation strings, reactivated 40-ish plugins, everything besides Image processors, CDN stuff and W3TC, reloaded every admin page in a couple of seconds. CPU load drops to 9%!
Finally, I activated W3TC, and reloaded admin pages again CPU load drops again to 5%
Which really narrows it down to a WPML version issue.
You should be able to see this also with the package I provided you with.
What is this script, and how can I get rid of these calls?
This behavior puts our servers down.
I deployed the package and I can see the WPML trying to make this request consuming CPU.
I found this because the site is running on local and the SSL certificate is invalid due to this it says REST is disabled in WPML > Support: under title "WordPress". Once I change the URL from HTTPS to HTTP the issue is fixed, WPML makes only one request and then no more requests.
Since I can not see your local site but I am guessing that you have the same issue, the SSL certificate is invalid or valid only locally.
Could you please remove the https from site URL and try on http does it fix the issue?
If this is the problem then I would suggest testing on a live staging server with a valid SSL certificate.
The SSL certificate is wrong locally, but it's absolutely fine in bot production and preproduction envs, where the requests also occur.
If this was the issue, I would have faced it on both local env, so before and after the WPML plugin update.
Still, as switching from https to http solve it for you, it's probably something related. Any further idea?
Screenshot is our production env. As you can see, REST is fine, but requests still occur.
