We have completed the staging environment as requested, but after thorough testing the performance issue cannot be reproduced there. This was expected, since staging does not replicate the same live conditions:
No real traffic or concurrent users.
No heavy load from scheduled tasks (cron jobs, WP Rocket preload, RankMath, backups, etc.).
Database activity is much lighter compared to production.
For this reason, the staging environment cannot reflect the actual bottleneck we are facing. The slow queries appear only under live traffic conditions, which is why we have already provided you with detailed MySQL slow query logs (including the 3-day report). These logs are direct evidence of the problem and point clearly to queries related to WPML.
Therefore, instead of relying on staging or video reproduction (which cannot capture the issue), we kindly ask your team to focus on:
Reviewing the slow query logs already shared. Suggesting concrete solutions or optimizations for the queries that WPML triggers under live load. The issue is well-documented, and we now need actionable recommendations from your side.
Please note that if you wish to check anything at clone site, we have restore your access to hidden link with the login credentials that i have already provide you above
Thank you for your continued support — we are looking forward to the next steps.
I understand your point, but as mentioned a few times before, there isn’t much we can determine from the logs alone. Performance issues can be caused by many factors, such as plugins, server load, or other external reasons. Unfortunately, based only on the logs, we cannot provide deeper insights.
We also weren’t aware that the issue occurs only on production and under heavy load, since our checks were done on a copy of your website. To move forward, we would need a way to properly reproduce and debug the problem, as without direct access it’s very difficult to diagnose or recommend anything specific.
In the meantime, one step you could try is disabling some plugins (other than WPML) to see if that improves performance, as well as using Query Monitor to identify slow-loading queries.
Other than step suggested, I’m afraid we are stuck at this point, since we cannot see or reproduce the issue ourselves. Please check with your team and try to provide us with a way to reproduce on a staging site, local environment, or through any testing tool—so we can investigate further.
However, after weeks of back-and-forth and despite the fact that we have already provided detailed live MySQL slow query logs clearly pointing to WPML-related queries, your team is unwilling to analyze them in depth or provide concrete solutions. Instead, we have been redirected to generic troubleshooting steps and suggestions such as “disable all other plugins.”
This is not a serious way to handle such an issue. It is not realistic — nor acceptable — for a production e-commerce website generating more than €500,000 annually to disable essential plugins just to prove a point, especially when the logs already demonstrate that the bottleneck originates from WPML.
For a professional product like WPML, we expected a serious technical investigation. Unfortunately, the handling of this case has been very disappointing.
At this point, since WPML support cannot or will not work with the evidence provided, we have no choice but to proceed with a refund request and begin the process of replacing WPML with a competing solution. Sadly, our experience with WPML support has been extremely negative.
Before closing this case, please confirm:
For how long do you still require access to the staging site (hidden link
)?
If you have any final remarks or technical insights to share, please do so now.
After that, we will proceed with shutting down the staging environment and requesting a refund.
I’m sorry to hear you feel this way. Please know that we’ve been doing our very best to support you. We’ve been working on this case for several days, but unfortunately, we haven’t been able to reproduce the issue or make further progress beyond reviewing the SQL queries.
As mentioned, both myself and our second-tier support team have examined the queries in depth, but it’s difficult to draw definitive conclusions from them alone. Many different factors could be contributing to the slowdowns. Based on the logs shared and the copy of your website provided, there isn’t much more we can determine at this stage.
The steps I’ve suggested are meant to help move us closer to finding new clues or solutions—not to lead you in the wrong direction or provide generic advice.
To ensure once more nothing is overlooked, I will review the case again with our second-tier support and escalate it to our manager to see if there’s anything further we can try or recommend.
Please allow me a little time to follow up with them, and I’ll share any updates with you as soon as possible.
Please note that this issue is business critical for us and cannot be prolonged any further. We have already invested significant time and resources, and the backend performance directly affects our daily operations.
I appreciate that you will review this again with your second-tier team and escalate it to your manager. Please proceed, and let me know as soon as you have a concrete update.
Thanks for the reply, and I understand your side and affect it has.
Please try next suggestion from our 2nd tier, based on the finding and clues we have had from the copy of the website:
- Reevaluate the need for the WPF Product Filter:
This plugin creates temporary tables populated with large data lookups, which can have a noticeable impact on performance.
- Replace WordPress cron with a real server cron job:
Disabling the built-in WordPress cron and setting up a proper system cron will prevent constant updates to the “cron” value in the options table, reducing overhead.
- Optimize database configuration:
Consider increasing the innodb_buffer_pool_size value to improve database performance and query handling.
- Enable WooCommerce HPOS (High-Performance Order Storage):
At the moment, orders are stored as regular postmeta entries, which leads to very large and slow tables. Migrating to HPOS can significantly reduce database load.
Each of these steps can contribute to reducing bottlenecks and improving the site’s overall speed and stability.
Please review these options and try to follow them. Let us know how it goes and if this helps.
Thank you for the detailed suggestions. This is more concrete and helpful.
Database optimization: Our sysadmins have already adjusted the innodb_buffer_pool_size and related parameters as part of the recent tuning.
Server-side cron: We fully agree this is important, but it must be done with a safe migration plan to avoid breaking essential plugins (e.g. backups, RankMath, WP Rocket). We will review this carefully before applying it in production.
WPF Product Filter: We are aware of its impact and will evaluate if further optimization or caching is possible.
WooCommerce HPOS: This looks like a critical improvement for scaling. We plan to test the migration first in staging before applying it live.
One important question: does WPML have full compatibility with WooCommerce HPOS? If yes, could you please share official documentation or best practices for enabling it together with WPML? This will help us plan the migration safely.
Thanks again for your support. We will proceed step by step and update you with our results.
Thank you for getting back to us and considering our suggestions.
Please let us know the outcome once you’ve had a chance to review these with your team and test whether they help.
Regarding WooCommerce HPOS, I can confirm that WPML is fully compatible and there are no known issues related to this functionality. Support has been available since 2023—you just need to enable it on the WooCommerce side by selecting High Performance Order Storage in WooCommerce → Settings. Of course, you need to have installed and enabled "WPML for WooCommerce " add-on plugin from WPML, before it was called WooCommerce Multilingual, just to not cause any confusion to you.
For reference, here’s our announcement on full HPOS support:
Thank you for getting back to us and for sharing more details. I understand what happened and how it occurred, but unfortunately, based on the information provided, it’s still difficult to identify the exact root cause — as mentioned earlier.
Please let me know how it goes after following our suggestions and whether that helps. If you’re able to reproduce the issue or share access to the affected site, we’ll be happy to investigate it further in depth.
I will wait for your update.
Kind regards,
Dražen
The topic ‘[Closed] WooCommerce + WPML very slow backend due to heavy SQL queries’ is closed to new replies.
