Sumit
Supporter
Languages:
English (English )
Timezone:
Asia/Kolkata (GMT+05:30)
|
Hi,
Yes, you are right I also changed WPML ATE setting after changing the URL from https to http, so this is not SSL issue.
Anyway, I can see the problem. The AJAX is fine but this AJAX request also triggers an external REST request to our server, this request returns a communication error (you can see this in response of any of the requests). It is all related to Advanced Translation Editor. I tried many ways to reproduce this issue on my test site but I can not.
On my test site if ATE is not active this request is not fired not sure why on your site it is in the loop even when ATE is not active.
I will continue debugging to see if I can find the culprit. In meantime, here is the quick fix:-
1. Please go to WPML > Settings, then activate Advanced Translation Editor
2. Once activated successfully then change it back to Classic translation editor or Advanced translation editor whatever you like. Then refresh the page and check again the request should be gone.
Thanks
|
T4ng
|
Hi Sumit
Ok, I'll try this on the preprod.
Once I first moved th ATE (before moving back to CTE), what should I do here ?
|
T4ng
|
I clicked classic in the first setting, then saved.
The result looks good:
- no more app.js requests
- with 12 admin pages open, we drop from over 40 to 23% CPU load on this server
- I checked the Classic Editor was still the one offered
|
Sumit
Supporter
Languages:
English (English )
Timezone:
Asia/Kolkata (GMT+05:30)
|
Hi,
Thanks for the feedback.
Now, you can keep whatever editor you like. We recommend Advanced Translation editor which offers more features than a classic editor but it is not a must. If you like to translate with a classic editor then keep using it.
About the issue, I tried multiple ways but I can see the problem on our test sites. It seems the problem was due to temporary values in the database that are removed/changed once we change the Editor setting.
Let me know if you have more questions.
Thanks
|
T4ng
|
Unfortunately, after:
- Doing the setup change back and forth as suggested, and save
- Purging all W3TC cache, Autoptimize, OP Cache, and doing a Cloudfront invalidation
- Closing all the admin pages
- Purging the browsers caches
... In production environment... nothing better.
It didn't drop the server load. Server resources usage remains exactly the same as before.
|
Sumit
Supporter
Languages:
English (English )
Timezone:
Asia/Kolkata (GMT+05:30)
|
Hi,
On my local server after fixing those continuous requests the CPU load is almost zero. The CPU is optimized only when there is a request, like a page load.
And you also confirmed that the issue of the continuous request has been fixed.
Do you mean the site is still consuming CPU and even the requests issue is fixed?
If this is the case then, please provide me production site details with the steps to see the issue? I am enabling the private reply.
Instructions to send private information are here: hidden link
Privacy and Security when Providing Debug Information for Support:
https://wpml.org/purchase/support-policy/privacy-and-security-when-providing-debug-information-for-support/
Thanks
|
T4ng
|
Yes, that's what I say. the server load seen via Plesk remains as high as it is for 2 months now, while I can't see the apps.js anymore (only 2 resquests when loading an admin page, but no more).
|
Sumit
Supporter
Languages:
English (English )
Timezone:
Asia/Kolkata (GMT+05:30)
|
Hi,
Okay, I can not say about the server because I don't have access to the server to check.
What I can do I will install a query monitor to check the status of the query and PHP output, to see the load time with and without WPML.
Because the server could be slow for many reasons but we can not debug that we can only check WPML issues. If I see the load time is increased by WPML more than expected then I will continue checking about the culprit.
For that, please provide me staging or production site access to check. Because on our server it is pretty fast.
Also, I would suggest restarting the server once after you have done the changes, this will kill the process if those are still running due to previous requests.
Thanks
|
T4ng
|
Hi Sumit,
Again, we're not really keen offering you access to our production environment.
However, I just realisized I still faced, ramdomly, pages initiating these mutiple app.js requests on production environemnet, even if I applied the setting you asked.
It's just random. This doesn't seem to happen on a specific admin page, it just doesn't happen everytime an admin page is loaded.
I can load one specific admin page, without many app.js request, then 2 minutes after, if I reload the same page, I'll get these requests.
I purged, then disabled W3TC, disabled autoptimize, purged opcache, invalided ClourFront, then applied the parameter again.
Cleared the browser cache, then connected again to the admin.
The issue remains
|
T4ng
|
I juste realized that these app.js requests don't occur anymore, at all, as soon as W3TC page cache is disabled.
When this page cache is disabled, the server load significantly drops.
Even with 12 admin pages open.
That's suprizing because this page cache has been active for years now, and didn't eat CPU until the last plugin update.
|
T4ng
|
Well... After extensive testings, deactivating, reactivating methodically cache plugins and their options back and forth, we finally seem to get to lower the CPU/memory usage AND get rid of app.js requests.
Finally, we got the whole setup back with the very same options as before, but don't face anymore issue.
While it's satifsfying to get back to normal, we don't really understand what's going on. I suspect some settings were somehow held in cache... We'll definitly keep an eye on this.
|
