Our WordPress backend is extremely slow and sometimes overloaded. After investigation with code profiler, we found out that wpml causes the issue with a massive amount of sql queries. From all 30325 Database Queries, WPML generates more than 29600.
Before this is taken by a colleague, let me share some thoughts and get some more information.
For us to be able to investigate this we would need to be able to access your site and do some testing, which may include installing some debugging utilities.
And that should really be on a staging site, as we may need to deactivate some plugins, switch theme etc..
Are you able to make a staging server available for testing?
Let me mark your next reply as private so that we can get log-in credentials from you—you may want to create a temporary admin user for us to use that you can later delete. And be sure to have a current backup of your site.
Can you also confirm the url that the profile shown in your screenshot refers to.
At the moment, i need to admit that i cannot reproduce it in staging. i will talk to the hosting provider guy who explained it to us and ask him to reproduce the issue. i will follow up on that as soon as i have an answer. until then, please stay on hold.
In your initial post you said the problem was in the backend, but the profile you just linked to is for a front-end page.
Looking at the profile it does show WPML as consuming the most time (plugins.php), but on that page you will notice a warning about the number of plugins using Composer, and how this might distort the time reported for WPML.
The full text of the explanation is here: hidden link
Composer is a shared library, and WPML happens to load it before all of the other plugins which also use it, which means their use of Composer to autoload classes gets attributed to WPML, so that WPML's execution time is distorted up and the times of all the other plugins which use Composer are distorted down.
And on the second tab (Scripts.png) it shows that the main "problem" script is the Composer ClassLoader script provided by WPML.
Discounting this, it's not obvious that there is a problem originating with WPML.
I temporarily activated Query Monitor to inspect the queries for the test page, but it doesn't seem to work on the front end for some reason, so I wasn't able to go any further.
For this profile you are absolutely right, it's maybe a partly problem - but please have a look into all latest profiles of code profiler -
especially following:hidden link
This was a test on following backend page: hidden link
something is happening in backend which refers to wp4s_icl_translation
what we recognized is, that it not suddenly happens or perexists - its kind of building up after a while (after restarting the server). sometimes it takes hours, sometimes days... but after a while, its getting worse each minute.
it's hard to reproduce it as we have no clue why it happens. but what we see is in code profiler database queries. The screenshot attached was at a time where we were able to track it. and this message you see here came in literally 30k times...
When I visit the same page you referred to after activating Query Monitor it looks pretty normal (screenshot), so I only have the profile results to go on in terms of evaluating what might be wrong.
There is one thing that jumps out in the profiles to me that I'd like to fix, and then run some fresh profiles without that distortion so that we can get a cleaner look at page loading process.
Some of the profile results are more affected than others by this code that you have added to your child theme's functions.php:
On every page load you are triggering the WPML plugin activation code (i.e. the code that runs when you first activate the WPML plugin). As you can imagine that does a lot of tasks such as checking the existence and integrity of the WPML database tables which are redundant when loading pages (front-end or back-end), and I can't imagine why you are running that code from your child theme.
Please edit the file and remove that code to provide more of a clean slate for testing.
The topic ‘[Closed] Massive SQL Query Requests when WPML is active’ is closed to new replies.
Manage Cookie Consent
We use cookies to optimize our website and services. Your consent allows us to process data such as browsing behavior. Not consenting may affect some features.
Functional
Always active
Required for our website to operate and communicate correctly.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
We use these to analyze the statistics of our site. Collected information is completely anonymous.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
These cookies track your browsing to provide ads relevant to you.