Home › Toolset Professional Support › [Resolved] Slow queries leading site to 502 error
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
This topic contains 5 replies, has 3 voices.
Last updated by Christopher Amirian 8 months, 2 weeks ago.
Assisted by: Christopher Amirian.
Tell us what you are trying to do?
We noticed a slow queries that making the website down frequently for past few days.
We have contacted our hosting they requested to optimize the database, solve slow queries. We do have WP DB Cleaner that have our database optimized and we noticed the slow queries in on terms and taxonomy table.
I have attached the screenshot of one of the slow queries when i click post type on the backend.
Please guide me how to resolve this issue
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
Hi there
From the number of rows returned by the query (33217) it is clear that this is a large site, and as such a large site needs commensurate server resources to function well.
Can I ask you to go to the admin page Tools > Site Health > Info, copy the site info to the clipboard and then save that as a text file and share the file with us via dropbox, wetransfer or similar? (Such a link will be hidden automatically, keeping it private. We would normally ask for your Toolset debug info, but the Site Health info includes some extra info that gives a fuller picture of your site.)
I'm not sure how much we can help.
If you look at the query in your screenshot, it's a normal WordPress query using get_terms, and it is slow because your site appears to be large, putting pressure on the server.
In the Caller column if you expand the section under the + button it should give more information about what made the get_terms call. Can you do that and share what it shows?
Hi Nigel,
Thanks for supporting us.
Yes i can share the health info. I noticed this conversation is not private . Can you please open a private one where we can leave details so I can provide the link of the file there.
I have attached the screenshot of the query caller
Thanks for the support
Hi there,
You will have an option on the next reply to set it as private to share the link to the file my colleague mentioned.
Upon checking the screenshot you shared, Toolset is not the initiator of the big call.
I wonder what led you to think Toolset has anything to do with the issue at hand?
Thanks.
Hi,
Here is the link for health info: hidden link
We noticed most of the slow queries are showed when we click post types and queries are wp_term, relationship, taxonomy thats the reason we thought of checking with Toolset.
Thanks in advance,
Hi there,
Thanks, the Site Health did not give information that Toolset might have in play here as my colleague mentioned the queries are normal WordPress ones.
Even the post types or taxonomies created by Toolset are created with standard WordPress functions.
I can also take a look onto the backed to see if there is something that can be detected?
I'd appreciate it if you could give me the URL/User/Pass of your WordPress dashboard after you make sure that you have a backup of your website.
It is absolutely important that you give us a guarantee that you have a backup so if something happens you will have a point of restore.
Make sure you set the next reply as private.
I also think it would be a good idea to check if the post types other than Toolset have the same issue? That will confirm
- IMPORTANT STEP! Create a backup of your website. Or better approach will be to test this on a copy/staging version of the website to avoid any disruption of a live website.
- Go to "WordPress Dashboard > Plugins" and deactivate all Toolset plugind
- Check if you can see the slow queries for other post types
Hi,
Thanks for the support.
We noticed slow queries with other plugin when we deactivated the Toolset. we will also try to resolve this.
Our 502 issue is fixed after some optimization. So i am closing this ticket.
Thanks again for the support.