Faisal is off today, so I am taking care of this ticket, hope that is OK. 🙂
I apologize for taking so long, and thanks for your patience. The case and your website is having a very specific issue that you reported and our team is doing its best to try and find a workaround to help you out.
As it seems already suggested workaround hasn't helped you much, we need to try and find a different approach here. I ask you for a bit more patience as these cases can not be debugged and solved in 1 action.
Anyway, from my side, I will check with our management and developers and try to prioritize this ticket and get back soon to you with and conclusion or solution. 🙂
Good morning. I apologize for the delay in providing a potential solution. Our second-tier support team is still working hard to resolve the issue, which is unique and thus taking a bit longer than expected.
I kindly ask for your patience as we need a few more days to investigate. As soon as I hear back from our team, I will be sure to provide you with an update.
Hello Faisal
it's been 2 months!
No news from the support
On our end we are 100% sure WPML cause the issue and the site is slow.
As soon as the WPML is turn off all issues are gone and the page load is around 1 sec. (no cache plugin in use)
Please let me know how to solve all the problems WPML is causing!
Thanks
Ricky
I understand that you are concerned about the issue, and I sincerely apologize for the inconvenience caused. Our team has worked diligently to resolve the issue, but unfortunately, we face some unexpected challenges.
We are doing our best to find a solution as soon as possible, but at this time, we are unable to provide a specific timeframe. I want to assure you that we take this matter very seriously and are committed to providing the highest level of support to our valued clients.
We appreciate your patience and understanding in this matter. If you have any further questions or concerns, please do not hesitate to contact us. We will keep you updated on the progress and let you know as soon as a solution is available.
If I were in your place and that of the programmers I would be very ashamed. This ticket has been open for months and you can't find the problem that your plugin creates to slow down the site!...
I am speechless
I am one of the team leaders in WPML support, and I wanted to add my reply here, in order to try and clear this situation a bit hopefully we get a bit more time and patience from your side.
Please note our management and developers are aware of this ticket, we understand your frustration and we are very sorry for the inconvenience it caused you.
We suspect what is causing the problem here, and to be similar to the errata page we first shared with you. Since the fix from that errata doesn't help in your case we needed and need more time for investigation. It is not an easy fix.
To be fair to you, considering our current priorities, this may not happen in the next few weeks. Our developers are working on preparing the products for the new WordPress release, which is why we haven't had lately many updates or progress here.
Also, to be aware, for now, the fix for this related issue, which would help in your case, is set for WPML 4.6.4 development cycle and we don't have any ETA for this yet.
As soon as possible our developers will further check the related issue and work on a relevant fix, but for now, we need a bit more patience from your side.
Be sure, we will update you as soon as we have some news.
I am George from the second tier support team.
I am in charge of managing your ticket. As I escalated the case to our developers they reviewed more in-depth the performance problem that you reported and they have given me their response with some tips that you can try.
The problem mainly appears to be related to the Redis cache that your site is using.
During my initial debugging, I found out that your site becomes faster if I block external HTTP requests.
These external requests seem to be related to checking for updates - which is normally done every 12 hours (twice daily).
Our developers have determined that these requests happen because the value returned by the transient - get_site_transient('update_plugins') is not returning the last_checked time. Thus the check is done on every load.
During their investigation, when they disabled the cache, the site dropped loading time from 1minute to less than 7secs.
Their suggestion is to look upon your redis cache and try:
- Enable WP debug login and check the debug.log file to see if there are any Redis-related errors. I found that if I stopped the Redis service on the server, there were Redis connection errors.
- When the performance issue occurs, disable the "Redis Object Cache" plugin to see if performance is improved.
- flush out the Redis cache using redis-cli FLUSHALL.
Since the plugin update is run every 12 hours, there is likely to be a performance issue at least once a day, even if the transient is being set correctly. So a second page refresh should be done to check if there is still an issue.
Good morning,
I totally disagree with what you wrote.
Redis has nothing to do with the problem!
Also this statement is bizzard:
During their investigation, when they disabled the cache, the site dropped loading time from 1minute to less than 7secs.
The site loading is 2,5 seconds for logged in user (not 1 min) not cached
When I turn off WPML the site loads less in 1 second per page (not caches)
So there's no doubt for me the WPML caused the problem
I invite you to look to the production site, because from what I understand with your copy stage site there's issues form what you wrote.
Hello!
First, let me say that runtime results will definitely be different for you than the things that we can see in our development environments. This depends on the server and configuration that you are using.
I provided you with the exact values that were mentioned to me by our developers. We tested on a testing server and that server, I am 100% certain, has lower specs than your actual production server.
During our testing, we deployed your site, as I mentioned and investigated the possible issues with running a PHP profiler. Our developers used hidden link, and I used xdebug/xprof to profile your site.
Our findings determined that there were a lot of external calls from your site and our developers determined that this is because of the update checking for the plugins that you have and the transient (update_plugins) not setting and returning the correct values.
Perhaps you can try by temporarily placing this declaration in your wp-config.php to verify if this helps you:
define ('WP_HTTP_BLOCK_EXTERNAL' , true);
But then after testing, it is probably better to remove it as calls to update plugins, for example, will fail.
For your load values - 2.5secs is definitely not that bad of a value actually.
Everything depends on the page that you are visiting and the values that have to be adjusted and loaded. I hope you understand that every plugin takes its toll on the site load, and WPML in order to display the proper values have to adjust the data loaded by the other plugins.
Hello,
clearly I use an 8 core dedicated server with 32GB.
2,5 sec load is not bad but can be much better and this happens when I turn off the WPML. This problem has been around for about 5 months. After WPML update.
I conveyed your message to our developers. They are taking another look at the problem, ignoring the one created by the updating of the plugins check and the caching issue that they encountered.
