Performance problems / crashing servers

[stuartcusackie]

Hi, I'm looking for some advice as I'm a little worried about launching an upcoming image-heavy website that has hundreds of pages and gets a good bit of traffic.

The heaviest image generation is done on the photo gallery pages, which each have about 40 high-res images, each uses the @responsive tag in blade. There are also another 10 or so smaller images on these pages.

The staging server, a micro EC2 instance, struggles when opening these gallery pages. It gets faster after the first render but the first render can crash the server if I resize my browser on these pages - As many batches of requests are sent off for new image sizes. The live server will be 2 or 3 times more powerful so I'm hoping that this will improve.

I opened this originally when I was experiencing random freezes on pages that I'm sure had already had images fully generated but these freezes seem to have abated.

Has anyone got any recommendations about how to improve this or reinforce my deployments? I am considering the following:

• Set up a job queue to visit each page and request all image sizes after deployment (this works very well - see comment below)
• Use local hosting instead of remote - I have a feeling the S3 requests for the original files are expensive operations.

UPDATE: I have set up a package for queuing a request for every image size and it works very well. See comment below.

[ncla]

Downscaling the high-res, original images can also help reduce page load times. I did test a while ago where I had a gallery with multiple high res images that got manipulated on ssg:build. I did small benchmark, one where the images were original resolution (e.g. 6000x3000) and another where with lower resolution.

glide:clear + cache:clear, original images: 89.40s
glide:clear + cache:clear, resized images: 53.38s

You could also only generate one image format, although you currently cannot disable default format generation (JPEG/PNG). Only WEBP and AVIF.

Setting glide:width to limit the amount of image width variants get generated could also help. Passing glide:width will consider the width as a max width, which can prevent unnecessary large images from being generated.

[stuartcusackie]

Thanks for the advice. I always set the max width in the config file to about 2500 or so.

I'm hoping Statamic eventually adds some rules to asset containers to restrict or resize large files: statamic/ideas#619

[stuartcusackie]

Some updates on this....

My website has around 700 images, which doesn't seem like much. However, when using this responsive package the site is generating over 20,000 image sizes and fall backs from these 700. Server crashes are still occurring for my image gallery pages, which spit out a couple of thousand image sizes per page. If the browser makes 50 requests for image sizes that have not yet been generated then the server starts struggling, especially when these images are hosted remotely and some of them are over 15mb.

Of course this will level out over time as visitors initiate image generations for every page, and eventually the site will run smoothly. I just don't want to showcase a site to my clients while it is slow and going through this process.

So I went ahead with my idea of setting up a Laravel queue to request each image size after deployment. It works very well and every page on the website is fast straight away because images are pre-generated. You can check out the package here:
https://github.com/stuartcusackie/statamic-glide-requester

[ncla]

What do you have set for config.statamic.assets.cache? Having it on true pre-renders/saves all Glide manipulations on a page load. But because we are using this addon, it is not strictly necessary as from tens of the images generated, only one gets requested on page load, which is determined by browser.

[stuartcusackie]

I have it set to false. When set to true things get very bad.