Forum

Thread tagged as: Question, Runway

Separating perch field groups in a runway collection template out into separate...

Is this possible? I find that when I have to make a small text change to a collection item with a lot images (i.e. a gallery), Perch can be very slow to update on save, presumably because it's gotta check through all the images (& all the various sizes required for responsive images).

It'd be great if we could separate the images (or the new field groups) onto a separate (sub)edit page to speed up text only updates. I realise this might be possible by creating multiple collections then using associations to link them up but it doesn't seem like the most intuitive approach from a user perspective, and seems considerably more complex on the coding / dev side.

Perhaps something like a 'separate' attribute on the Perch field group which could create a link to a sub-edit page for that group, i.e. ...

<perch:group label="Gallery images" separate>
...
</perch:group>

Are there any other approaches to improving this?
Adam Green

Adam Green 0 points

  • 3 years ago
Drew McLellan

Drew McLellan 2638 points
Perch Support

3 years ago

Have you profiled to see where the slowness actually is? If not, put your site into development mode and turn on debug to see the timings.
Adam Green

Adam Green 0 points

3 years ago

Thanks Drew, I hadn't thought of that. Here are 2 of the seven queries flagged red (most are yellow):

7.9992 1.133 [1] SELECT * FROM perch3_resources WHERE resourceAWOL=0 AND resourceParentID='2' AND resourceTargetWidth=1920 AND resourceTargetHeight=0 AND resourceCrop=0 AND resourceDensity=1 12.0445 2.0716 [1] SELECT * FROM perch3_resources WHERE resourceAWOL=0 AND resourceParentID='241' AND resourceKey='thumb'

18.0517 0.0076 Mode: edit.form 18.0517 0 Queries: 159 18.0517 0 Memory: 51.6088

This is from a standard page with content regions using blocks and about 15 gallery images (on S3 / Cloudfront CDN), no collections. It's always the image related queries that are slow / in the red. Is this a server resources issue? or an S3 issue?

It is on a Memset shared hosting platform but either way, 10 to 20 seconds for each save / update is frustrating.

Adding gallery images is a real issue too as only 1 or 2 can be added at a time - some kind of background image processing queue for large batches of images would be massive time saver. Any further thoughts on how to improve?

Thanks again!
Drew McLellan

Drew McLellan 2638 points
Perch Support

3 years ago

The red flag points indicate that there's been a big time difference between the previous timing point and the current. So if a line is flagged red, it's usually the query before that line that is slow.

It shouldn't be taking anywhere near that time to save.

some kind of background image processing queue for large batches of images would be massive time saver

Yes, that's how I would build it if I had control over the hosting, but as you say, you're running this on a shared hosting account. Options like task queues simply aren't available to me here.
Adam Green

Adam Green 0 points

2 years ago

Thanks for that Drew - point taken re task queues! Here's a red flag query including the line before:

8.7822  0.0676  [1] SELECT * FROM perch3_resources WHERE resourceAWOL=0 AND resourceParentID='1273' AND resourceTargetWidth=360 AND resourceTargetHeight=0 AND resourceCrop=0 AND resourceDensity=1  
11.4761 2.6939  [1] SELECT * FROM perch3_resources WHERE resourceAWOL=0 AND resourceParentID='1273' AND resourceTargetWidth=1920 AND resourceTargetHeight=0 AND resourceCrop=0 AND resourceDensity=1

Is the problem most likely to do with the host choking from to the volume of mysql queries (near 160)? Would reducing the volume of queries by separating gallery images into a different content region help?

Or could the problem be related to using template includes within other template includes? Is this bad practise?

i.e. default_template.html:

<perch:blocks>
    <perch:template path="_content_blocks.html" />
</perch:blocks>

& _content_blocks.html:

<perch:block label="Paypal Button" type="paypal_button" icon="cart">
    <perch:template path="content/blocks/_paypal_btn.html" rescope="parent"  /> 
</perch:block>

<perch:block label="Photo" type="image" icon="photo">
    <perch:template path="content/blocks/_image.html" rescope="parent"  />  
</perch:block>

<perch:block type="video" label="Video" icon="video">
    <perch:template path="content/blocks/_video.html" rescope="parent"  />  
</perch:block>

<perch:block label="Map" type="map" icon="location">
    <perch:template path="content/blocks/_map.html" rescope="parent"  />    
</perch:block>

Many thanks!
Drew McLellan

Drew McLellan 2638 points
Perch Support

2 years ago

Neither should be a problem. 160 queries is obviously quite a lot, but sometimes quite a lot of queries are needed! Mostly those should all be very simple queries that wouldn't tax the database at all.

How large is your perch3_resources table?
Adam Green

Adam Green 0 points

2 years ago

Thanks Drew there's about 1800 rows - is this likely to cause a problem?

I tried it on my local MAMP server also and getting similar delays. After upgrading to MAMP 5, the default version of php went to 7.2.7 & the debug output the following error at the very bottom:

14.578  0   Queries: 159
14.578  0   Memory: 51.4361
14.578  0   
Array
(
    [type] => 2
    [message] => count(): Parameter must be an array or an object that implements Countable
    [file] => /Users/adam/Sites/ballyvolanehouse.ie/site/perch/core/runway/apps/perch_s3/lib/guzzlehttp/guzzle/src/Handler/CurlFactory.php
    [line] => 67
)

Switching back to php 7.0.30 & this warning disappears - not sure if it's relevant?

All the images and resources are on Amazon S3 / Cloudfront and this is set as the default resource bucket:

define('PERCH_RESFILEPATH', PERCH_PATH . DIRECTORY_SEPARATOR . 'resources');
define('PERCH_RESPATH', 'https://cdn.ballyvolanehouse.ie');
define('PERCH_DEFAULT_BUCKET','assets-cdn');

Is there something in the S3 integration that's likely to cause the bottleneck? I'm not experiencing these sort of delays on other sites when resources are hosted locally! Thanks again.
Drew McLellan

Drew McLellan 2638 points
Perch Support

2 years ago

Thanks Drew there's about 1800 rows - is this likely to cause a problem?

No, that's not a lot of data at all.

Is there something in the S3 integration that's likely to cause the bottleneck?

Yes, network latency. Working with a remote file system across the internet will always be much slower than working locally.
Adam Green

Adam Green 0 points

2 years ago

Thank you Drew, I guess this is a downside of using this kind of CDN - will investigate other options!
barry allen

barry allen 0 points

2 years ago

Is the problem most likely to do with the host choking from to the volume of mysql queries (near 160)? Would reducing the volume of queries by separating gallery images into a different content region help? https://snaptube-downloadapp.com/
barry allen

barry allen 0 points

2 years ago

Have you profiled to see where the slowness actually is? If not, put your site into development mode and turn on debug to see the timings. https://popcorntimeapk.org/