Hi Alejandro,
Thank you for your message. This sounds very good. I cannot recall that I have ever been looking so much forward to September 😊
I know you already have a copy of our site, but this is more than 2 month old, so In case you have a prerelease of the software that you would like us to test at our staging site, then please reach out. We will be happy to spend some hours on that, as it is of crucial importance for us to have this issue solved.
Hi AleJandro and Christopher,
We have now deployed and tested version 4.6.6 at our staging server. We cannot see any changes.
We monitored the sql statements while running the latest version. Please see pdf1
When running the captured statement it still produces 400 rows with only 20 unique rows (and a lot of duplicates). Please see pdf2
I would be grateful if your developers will look into it and get back to me.
Hi,
Would it be possible that this ticket can be handed over to another supporter for a second opinion?
We are having loading times of up to 12 – 15 sec. for some product category pages, and it is causing great harm to our business.
We have now been waiting 4 months for a solution to this bug, and I would like to be sure that this is not due other issues also.
Would it be possible that a supporter with large experience in WooCommerce (e.g. Marcel T.) could try and analyse the issue?
Access should now be granted.
For this issue it should not make a difference, but please be aware that this backup is from June 12, so it is not with the latest version of WPML and string translation.
I am working on this issue and it has been reported to devs already and they are improving the situation.
I took another look to find out what can be done meanwhile, and I noticed you did not follow the changes we proposed last time here https://wpml.org/forums/topic/performance-issue-21/#post-13764403
I have adjusted these settings on the staging site and I can see a few seconds of improvement and reduction in database queries by 100 (approx).
What we done
1. Disabled the plugins that are not needed and not being used by you on the site.
- WPML CMS Nav
- WPML Media (Not needed unless want to have different images per language)
- WPML Sticky Links
Please enable any or all if you are using them. But I am guessing you are not using them.
2. Set Post type and taxonomies to "Translatable - only show translated items" in WPML > Settings, This will reduce some SQL queries as this feature makes some extra queries and is expensive.
Now coming to the actual issue of "maybe_populate_cache" let me explain to you what it does. This function has a common name but is called by different functions e.g. when WP calls a term or calls a post. This interrupts the call and translates the ID of the post/term to the current language.
Since you are displaying a lot of categories in the menu and on the page WPML is trying to translate it so it is showing DB queries.
I know this won't be possible for you but somehow if you cache the result in transient and do not call on each load these queries will be gone too. We recommend this to a client some time ago but in your case it is Elementor so I think it won't be possible for you.
Now, meantime what other thing you can do apart from the above changes:-
1. Use Redis object caching. This is disabled on the staging site but if you enable it on the live site the calls will be cached. WPML optimizes the persistence caching when available.
2. Enable WP Rocket (already active on the live site but I disabled the caching for logged-in users for testing.) This will serve the static cache instead of stressing the server. This way your customer will see the super fast response.
I understand these are options for improvement but not the solution of the actual problem however, our devs are working and we have asked them to release this fix as early as possible.
I will update you as soon as we have the new release with the fix.
Please let me know if you need more general improvement suggestions.
I have been liaising with the developers on this issue. It is a complex task and work on it is ongoing, we are testing a number of different large client sites to understand the problem from all angles so that we can have a generic solution.
In the meantime I can share a patched version of the current 4.6.8 release of WPML which includes a minor change that improves the performance of the maybe_populate_cache queries, though it doesn't eliminate them.
These are directly related to the numbers of items being queried, so if you have a menu, for example, that lists many product categories and some widget listing related products which have many categories assigned, that will imply querying lots of terms and therefore caching attempts. You may want to simplify some of the content on your pages, as such content comes at a performance cost, particularly in the context of making it available in many different languages.
You can download a zip of the plugin here: hidden link
Remove your existing WPML plugin and manually upload this zip file.
(Naturally, please make sure you have a current backup before making any notable changes.)
While looking at your site I noticed some other things which can help with the performance.
The site is large. The wp_postmeta table is well over 0.5Gb alone. Other than simple get_postmeta calls, queries involving wp_postmeta are notoriously slow because it lacks useful indexes, and this accounts for why the many update_meta_cache() calls on your site are cumulatively very slow.
You may find it helpful to use the plugin Index WP MySQL for Speed to add indexes to most of the WordPress tables to improve performance.
While testing on my site it made a perceptible difference to load times.
I also noticed, when testing the shop page, that the results are ordered by the total_sales column of the wp_wc_product_meta_lookup table, which isn't indexed, so that will be a very inefficient query. Changing the ordering to a field such as post_date (to show the most recent products first) could speed up the main query (which is reported as slow whether WPML is active or not).
Finally, in your production environment make sure you are not using debugging tools like Query Monitor or Xdebug, as these add significant overhead and should only be used while investigating problems.
We will try and test the attached patched version of 4.6.8, as well as your suggestions for improving the database performance.
Our developers are currently quite busy with finalising a new frontend design where we get rid of the current theme and the page builder software. This is also with the purpose of improving performance.
We will need to spend a couple of days to do thorough testing of the patched version of 4.6.8 and due the current work load it might therefore take some time before we are able to do the testing.
Can you give any indication about when you expect to have final solution ready? The reason I am asking is for us to prioritize our resources in the best possible way. If you e.g. foresee that you will have the solution ready in 2 – 4 weeks, it might be that we should wait with updating WPML.
I checked the error report, there is no ETA for now but it seems to be more than 2-3 weeks as we are approaching the end of the year and most releases will go to Q1 of 2024.
I have the developers asking for feedback from your site, whether you tested the patched version yet and if you noticed any improvement.
(I don't have a date for when an update will be generally available as testing is ongoing and it depends on the results seen when testing on real-world sites.)
The topic ‘[Closed] Performance issue’ is closed to new replies.
