Here are my results after disabling all plugins except Toolset and activating the parent Toolset Starter theme:
Layouts - 45 queries @ 0.0058 seconds
Activate the child theme:
Layouts - 115 queries @ 0.0115 seconds
Can you rename the folder at wp-content/themes/toolset-starter-child/theme-dd-layouts to something like theme-dd-layouts-bak, then review the query results?
Ok seems we are getting somewhere. On my local dev machine it reduced the layouts queries from 144 to 62. Also no obvious difference in the layout - so what is the purpose of that folder? Can I leave it renamed on live?
I'm still quite suspicious of the layouts plugin if its doing 40 - 60 queries on a page load - far higher than wordpress itself, the theme or any other plugins. I've discovered another issue as well - woocommerce views running 140 queries on lien caché for example, but that may require its own support thread.
I'm reaching out to my 2nd tier support team for some additional information about this folder, and why it's present in your child theme. It's not part of the original download package, so I'm hoping they have some more information about it, and if it's safe to permanently remove it. Please stand by and I will update you shortly.
I've discovered another issue as well - woocommerce views running 140 queries on lien caché for example
Yes, let's track that in a separate ticket please.
It turns out this is a folder created by the Layouts export process. When compressed into a zip file, it can be imported into a new site using Toolset > Export / Import > Layouts. Once the import has happened this folder should be deleted from your theme, and the zip file can be maintained for future use.
Hi Christian,
Thanks for the feedback. I do export and import layouts quite a bit. I certainly wasn't aware that export/import files need to be deleted or will affect performance, i suggest that is a bug.
Although we have got a marked improvement, the queries are still very high. I think 61 queries for that layout on the home page is excessive.
It gets worse on other important pages, such as this one lien caché
Even with the layouts export folder gone, there are 205 queries running, taking 1.5 - 5 seconds. Please can you get your dev guys to look.
Okay sure, I've asked my 2nd tier supporters to investigate the high number of queries generated on this page. If I deactivate all the other plugins and activate the parent Starter Theme, I'm still seeing 127 queries from Layouts. If I delete this content from the WordPress Archive, that number drops to 48:
[wpv-post-link] in [wpv-post-link id="$project"]
<div class="photo-by">by <a href='/user/[wpv-post-author format="meta" meta="user_login"]'>[wpv-post-author format="meta" meta="first_name"]</a></div>
<div class="pin" ><a href="#add-pin" data-entity_id="[wpv-post-id]" data-user="[wpv-post-author]" data-type="photo" data-image_url="[wpv-post-featured-image output='url']" title="Save Photo to Ideabook" rel="nofollow"><i class="fa fa-plus-square" aria-hidden="true"></i></a></div>
Since 30 items are shown on the page, I'm assuming each iteration of the loop adds 2-3 queries to the page load time. I've asked for some clarification to see if that sounds normal, or if it sounds like something specific to your site. I'll let you know what I find out.
Thanks, now that i think of it by referencing a parent post type it will probably generate another query. To negate this I'd probably have to write a query filter to do a sql join onto the parent rather than use the view shortcodes. If this is true, then referencing parent posts via 'id=$[post_type]' in shortcodes in a loop is really not worth it, as I have a lot of parent/child and many to many relationships in the site which will make the number of queries explode.
Our 2nd tier supporters took a look and don't see anything highly unusual for Layouts here. The number of queries called by this archive, even without Layouts, is still around 80. None of the queries on our test environment are clocking at more than 0.5ms, which is our current benchmark, and we've got a total DB query time of 0.0365s with Layouts active. So even though the number of queries seems large in comparison to other plugins, this Archive / Layout combination does seem to be operating within our acceptable range. If you see a query that is consistently taking longer than 0.5ms, let me know and we can continue to investigate.
Thanks Christian,
Please ask your developers if referencing a types parent i.e. [shortcode id='$[parent_type]'] generates an extra query for each loop item or not, its quite important in terms of how i design loops. I changed the photo archive to join on the parent project post type in sql (using a filter) instead of referencing in the types way, but it doesn't seem to reduce the number of queries.
Regarding the layout query volume, I will just monitor query time, but it seems acceptable at the moment, after doing some tweaking.
Please ask your developers if referencing a types parent i.e. [shortcode id='$[parent_type]'] generates an extra query for each loop item or not, its quite important in terms of how i design loops.
Yes, information about a parent post requires an additional query, because parent post information isn't saved alongside child post information. You must use the child metadata to determine the parent post ID, then query that post ID.
A quick addendum to that - If more than one result in a View contains the same parent, then the cache may be hit instead of a full db query to get information about the parent. In these cases, the number of queries may not be exactly 1 to 1 with the number of results in the View.
Thanks for the info. I think then while in a loop I'll stick to doing joins and creating custom shortcodes to get out the data rather than risking firing new queries.
