Skip Navigation

[Resolved] Slow loading

This thread is resolved. Here is a description of the problem and solution.

Problem: Looping over repeating image field generates n^2 calls to Toolset_Utils::get_attachment_id_by_url

Solution: Update to the latest version of Types.

This support ticket is created 6 years, 4 months ago. There's a good chance that you are reading advice that it now obsolete.

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.

Our next available supporter will start replying to tickets in about 1.12 hours from now. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

Tagged: 

This topic contains 19 replies, has 4 voices.

Last updated by Timothy 5 years, 11 months ago.

Assisted by: Christian Cox.

Author
Posts
#921937

Hi,

I have a CPT called Galleries and in each Gallery I have an image field set to allow multiple images. I'm trying to output each Gallery's images on a page (and when clicked to open a lightbox with the full sized image) using code like this:

[wpv-for-each field="wpcf-gallery-images" item='6613' ]

<div class="col-sm-4">
<a class="lightbox-image" href="[types field='gallery-images' size='full' url='true' separator=',' item='6613'][/types]" target="_self">
[types field='gallery-images' width='296' height='197' align='none' resize='crop' separator=', ' item='6613'][/types]</a>
</div>

[/wpv-for-each]

This works but the page loads extremely slowly (I've put that code into the first tab):

hidden link

I'm using the Query Monitor plugin to find the cause and it looks like it may be due to get_attachment_id_by_url(). Any idea why this might be happening?

Tim

#921966

It's the "width='296' height='197'" in your second image:

[types field='gallery-images' width='296' height='197' align='none' resize='crop' separator=', ' item='6613'][/types]</a>

That is a custom size, not Registered by the theme.

Remove that and it'll load as fast as you expect.
That is, because Toolset needs to generate each of the images on the fly since not registered.

Count each such image, one second load time added to the query.

I suggest, not to use custom sizes like that but predefined sizes that "exist" in the database and files (hence, generated when you upload the image to the media)

#922039

Thanks. But I changed that to use the predefined sizes(large, medium) and the problem still persists:

[wpv-for-each field="wpcf-gallery-images" item='6613' ]
<div class="col-sm-4">
[types field='gallery-images' size='medium' align='none' resize='crop' separator=', ' item='6613'][/types]
</div>
 

[/wpv-for-each]

Tim

#922180

Hi, I'll be glad to take a closer look. Let's try to narrow down the issue.
- Please temporarily deactivate any other plugins besides Types and Views, and activate a default theme like Twenty Seventeen. Then test the page again a few more times and compare the initial markup download times.
- If the initial markup download times have improved significantly, reactivate your theme and plugins one by one and monitor the results each time. Check to see if any one plugin or theme is affecting the results dramatically.
- If the initial markup download times have not improved significantly, use Query Monitor again and check to see if any individual queries from Toolset are running longer than 0.5ms - our standard when debugging query times. If so, we can investigate those queries in more detail. If not, then there are a couple of other options to explore. You can try adding a caching plugin, which will significantly reduce the initial page load times. Usually this is the most practical approach. Or, you can consider restructuring this page to use less complex View filters or un-resized images. This isn't always practical.

#922219
Screen Shot 2018-07-08 at 2.37.21 PM.png
Screen Shot 2018-07-08 at 2.50.11 PM.png

I switched to a default theme and deactivated all plugins except Types and Views. The load time is reduced by 3-4 seconds but still at 8-9 second so the issue persists.

Query Monitor is showing me that "Toolset_Utils::get_attachment_id_by_url()" is taking me 7.43 seconds. There appear to be hundreds (looks like 800!) of these get_attachment_id_by_url() queries, many taking more than .02 seconds. When I look at the queries it appears each image has 20 database queries. 20 duplicates. So I guess the issue is all these duplicate queries?

Tim

#922632

Yes that seems unusual. Could I log in and see how this page and View are set up? I will activate private reply fields here so you can share login credentials.

#923105

Okay thanks, I was able to get the time down to about 5 seconds by adding output='raw' to the shortcode that generates the link href attribute, but it's still somewhat sluggish. I can try to work with a clone of your site locally to see if I can replicate the delay issue on a non-Flywheel server. I think Flywheel has some special rules about cloning plugins, so I need you to zip up your wp-content/plugins, wp-content/themes, and wp-content/uploads directories along with a database dump file so I can download them and work locally. You can provide a download link in the private reply fields here. Or, you can try installing a caching plugin to see if the results are satisfactory. Let me know how you would like to proceed.

#923124

I'm happy to create the zip files, but isn't this issue due to all the 20 duplicate queries for every image? That shouldn't happen right? I need to be add 4 or 5 galleries, like this one, on this one page so optimizing things really won't work if this duplicate query issue persists.

Tim

#923214

It seems for each image it's querying through all the images. so if I add a gallery with 10 images it creates 100 queries, if I add 20 images it create 400 queries. Could this be a repeating field bug with the latest version of Types/Views?

#923597

Sure, let me present this to my 2nd tier support team for further investigation. I am able to replicate the exponential queries in the latest versions of Types and Views, but not in the versions prior to Types 3.0. I'll ask if this is an optimization issue in an inefficient query, a bug, or maybe I'm not aware of a better way to set up this loop of images efficiently. If they need your specific files I'll let you know. I'll update you with whatever I find out.

#923777

Thanks, any idea when they might get back to me?

Tim

#924188

I'm not sure, initially they had trouble replicating the issue so I had to set up a testing environment for them where they can see it happening. I'm waiting to hear back from them now. I'll let you know if any solutions or workarounds are made available as soon as possible.

#950281

Any update on this?

Tim

#950487

No, unfortunately I don't have any news to share at this time. I can see the issue has been escalated to the Types developers as a performance problem, but I don't have a timeline available for a fix or workaround just yet.

#1129219
Screenshot-MH-20181017-9.png

Any news about this issue? I have the same problem... my code:

<a href="[wpv-post-featured-image size="large" output="url"]" data-fancybox="images" data-caption="[wpv-post-title] - [types field='woning-adres'][/types]">[wpv-post-featured-image size="medium"]</a>
[wpv-for-each field="wpcf-woning-galerijfotos"]
<a href="[types field='woning-galerijfotos' size='large' url='true'][/types]" data-fancybox="images" data-caption="[wpv-post-title] - [types field='woning-adres'][/types]"><div class="imgGallery" style="background-image:url([types field='woning-galerijfotos' size='thumbnail' url='true'][/types]);">
</div></a>
[/wpv-for-each]