Page loads with large memory usage ~100MB

[mgtcampbell]

Hi there,

I've developed a Statamic site and having some issues with initial page loads.

• I've turned off Stache file watching
• I've enabled half static caching

When pages are first loaded, the memory usage in Debug Bar are showing around 100MB, which seems very high and then drops down to ~3MB on subsequent page loads.

It seems the only real difference is that on the initial page loads it's loading all the stache indexes... though I wouldn't usually think this would cause such large memory usage.

I have a suspicion the main culprit may be the assets s3 path index, as the s3 bucket has many many files (part of the site development included porting over all image assets from an old Wordpress site, so each image has mutliple files for each thumbnail size generated).

What I'm wondering is if there's any way to drill down to test if this is actually the case? I can't think of how I could "turn off" assets/AWS and see if the performance improves. Also it doesn't seem in debug bar that you can get a breakdown of what makes up the ~100MB of memory usage.

I have looked at the size of the stache index files in my local dev, and the assets path one is 2.3MB which is much much larger than the rest - but individually nowhere near the total memory usage.

The staging site is http://worrells.staging.ply.digital/

Any thoughts would be helpful!

Cheers

[jackmcdade]

100mb to build the stache doesn’t seem that unreasonable to me. It’s only one request, after which all subsequent requests until the stache has been cleared will be real quick and light. Even the most minimal server plans tend to have 10x that memory.

Out of curiosity, what version are you running?

[mgtcampbell]

Thanks Jack... I didn't really have a frame of reference for memory size so all good if that's normal. I just assumed that was to blame for the sluggish lead times. I just updated to the latest version of statamic yesterday, as well as updating to PHP 8.1 and Laravel 9 (all as part of the effort to improve performance).

On Fri, 7 Oct 2022 at 10:26 am, Jack McDade ***@***.***> wrote: 100mb to build the stache doesn’t seem that unreasonable to me. It’s only one request, after which all subsequent requests until the stache has been cleared will be real quick and light. Even the most minimal server plans tend to have 10x that memory. Out of curiosity, what version are you running? — Reply to this email directly, view it on GitHub <#6841 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4VWDJ375OLH5LXNWDSUF3WB5U33ANCNFSM6AAAAAAQ7C5IOM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- [image: Where brands are built.] <https://htmlsig.com/t/000001FQ5N7T> Mark Campbell0431 626 082 Where brands are built. ply.studio

[jackmcdade]

We’ve been working through some S3 related performance issues lately, maybe try 3.3.39 for now and see if that helps while we work it out. On Oct 6, 2022, at 9:22 PM, Mark Campbell ***@***.***> wrote: Thanks Jack... I didn't really have a frame of reference for memory size so all good if that's normal. I just assumed that was to blame for the sluggish lead times. I just updated to the latest version of statamic yesterday, as well as updating to PHP 8.1 and Laravel 9 (all as part of the effort to improve performance).

On Fri, 7 Oct 2022 at 10:26 am, Jack McDade ***@***.***> wrote: 100mb to build the stache doesn’t seem that unreasonable to me. It’s only one request, after which all subsequent requests until the stache has been cleared will be real quick and light. Even the most minimal server plans tend to have 10x that memory. Out of curiosity, what version are you running? — Reply to this email directly, view it on GitHub <#6841 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4VWDJ375OLH5LXNWDSUF3WB5U33ANCNFSM6AAAAAAQ7C5IOM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- [image: Where brands are built.] <https://htmlsig.com/t/000001FQ5N7T> Mark Campbell0431 626 082 Where brands are built. ply.studio —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[mgtcampbell]

Thanks Jack will do On Fri, 7 Oct 2022 at 12:54 pm, Jack McDade ***@***.***> wrote:

We’ve been working through some S3 related performance issues lately, maybe try 3.3.39 for now and see if that helps while we work it out. On Oct 6, 2022, at 9:22 PM, Mark Campbell ***@***.***> wrote: Thanks Jack... I didn't really have a frame of reference for memory size so all good if that's normal. I just assumed that was to blame for the sluggish lead times. I just updated to the latest version of statamic yesterday, as well as updating to PHP 8.1 and Laravel 9 (all as part of the effort to improve performance). On Fri, 7 Oct 2022 at 10:26 am, Jack McDade ***@***.***> wrote: > 100mb to build the stache doesn’t seem that unreasonable to me. It’s only > one request, after which all subsequent requests until the stache has been > cleared will be real quick and light. Even the most minimal server plans > tend to have 10x that memory. > > Out of curiosity, what version are you running? > > — > Reply to this email directly, view it on GitHub > < #6841 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AA4VWDJ375OLH5LXNWDSUF3WB5U33ANCNFSM6AAAAAAQ7C5IOM > > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> > -- [image: Where brands are built.] <https://htmlsig.com/t/000001FQ5N7T> Mark Campbell0431 626 082 Where brands are built. ply.studio —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#6841 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4VWDNOGZCC4R6G5XWJGHLWB6GGXANCNFSM6AAAAAAQ7C5IOM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- [image: Where brands are built.] <https://htmlsig.com/t/000001FQ5N7T> Mark Campbell0431 626 082 Where brands are built. ply.studio