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.
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| - | 9:00 – 13:00 | 9:00 – 13:00 | 9:00 – 13:00 | 9:00 – 13:00 | 9:00 – 13:00 | - |
| - | 14:00 – 18:00 | 14:00 – 18:00 | 14:00 – 18:00 | 14:00 – 18:00 | 14:00 – 18:00 | - |
Supporter timezone: Asia/Karachi (GMT+05:00)
This topic contains 21 replies, has 3 voices.
Last updated by 3 years, 1 month ago.
Assisted by: Waqar.
Refer this ticket to Waqar.
Hi Waqar
I understand but this issue should be solved ASAP as it hugely affects our sales, clients and business!
Our server is not responding (and even goes offline regularly) and the site speed is VERY poor due to many inefficient queries that are executed in Toolset, as mentioned several times in previous threats.
Error message:
Deze site is niet bereikbaar
hidden link werkt even niet, of de pagina kan verhuisd zijn naar een nieuw webadres.
ERR_HTTP2_PROTOCOL_ERROR
See mobile screenshot attachment.
We have added two scripts for you on the server with which you can check it yourself:
This script would not load if the server is down, or if there are problems with the hosting:
hidden link
This script shows you whether the database is up or down, along with a bunch of other stats from which you can deduce whether the database is busy or not.
hidden link
In other words, if both links above load normally (and quickly), the problem is entirely with our Toolset instance.
When I look at the stats of the database (and you can do that yourself via the link above) I see that there are an average 77 queries per second. That in itself is not an abnormal number, but interesting is the number of slow queries (is now around 7.000 (!!)).
When we log in to the database ourself, I also constantly see queries that take up to 70 seconds (!!) and slow everything down. And that is a clear problem that needs to be solved ASAP. Ther problems are not caused by the server we have set up, or the database we have set up, or our configuration, but are entirely due to the code itself.
Hope to hear back from you very soon with a solution.
I've made the same changes on your site, which appears to be working much better, although not as well as on our test server.
While I was testing on that server, I had disabled most non-essential plugins to work on the issue more easily.
Your site has a lot of active plugins, which all influence performance. With the Query Monitor plugin added for debugging, it can be seen that page load times with these other plugins active more than double, given a 3-fold increase in the number of queries run.
As general advice, I would suggest you delete the 70+ inactive plugins on your server—they are just taking up server space—and review the active plugins to see if they are all really needed.
Also, it looks like you are accumulating post revisions and autosaves, which will increase the size of your wp_posts and wp_postmeta tables, and the size of your wp_postmeta table is particularly problematic, which I'll come back to.
I suggest you edit your wp-config.php file and add a setting to limit the number of revisions stored to whatever you think you need, maybe to just 1, and at the same time perhaps extend the auto-save interval to, say, 10 minutes, e.g.
define( 'WP_POST_REVISIONS', 1 );
define('AUTOSAVE_INTERVAL', 600);
Then use a plugin (e.g. WP Sweep: https://wordpress.org/plugins/wp-sweep/) to clean out existing revisions and auto-saves.
Regarding the property search page itself, I found several things that can affect performance, one in particular.
This is nothing to do with Toolset itself, but rather reflects the underlying architecture of WordPress. Specifically, it is extremely inefficient to filter queries using custom fields (i.e. post meta).
It is very quick to retrieve a post meta value so that it can be used or displayed, but if you query the database for posts and use post meta in the search parameters, that is extremely slow.
You wouldn't notice on smaller sites, but it becomes apparent on larger sites.
Checking the database, your site has 2.6 million post meta entries, so any query that is based upon post meta will inevitably be slow.
In the case of your property search page, when you first load the page and no filters have been applied, it was still extremely slow to load the page, and that is because the View was set to order the results by a custom field, meaning that every time the query runs the post meta table is included in the query, even on the initial load.
Changing that setting so that custom fields are not used for ordering was the single biggest factor accounting for the improvement in page load times. (Currently the order is set to random, which is what you had for the secondary sort option, but that likely means that the View cannot be cached, and so I would suggest an alternative, based on standard post fields such as post date or post title.)
In the back end it is still quite slow loading the page to edit, and—again—the problem lies with the size of your wp_postmeta table and how inefficient post queries filtered by post meta are. In the screenshot you can see an example of the results shown by the Query Monitor plugin when loading the page in the back end. The key point to note is that a query run by WordPress core (nothing to do with Toolset) is taking 17s to complete (the query is just to determine which meta boxes to include on the page edit screen). That's a direct result of having 2.6 million rows in your wp_postmeta table.
The other changes were less dramatic, but still helpful.
The View block has a setting "Don't include the current page in results", which in this context is redundant, but has a modest effect on the query times, so I disabled it.
The Map block had markers from the View added twice for some reason (the markers were duplicated, but you wouldn't notice looking at the map), so I removed one of the markers.
Lastly there was a broken distance filter in the View that wasn't shown on the front end, so I removed it.
Although the site is not quite as zippy as the clone we have on our servers that doesn't have all of the other plugins active, it appears to be significantly more useable and stable than before, if you'd like to check.
