One day after the release of the website of a medium sized travel company, I made a big mistake by accidentally taking it offline for 1 hour during peak usage (~150 simultaneous visitors).
Turns out deleting the wrong image transformation cache folder in production can hang up the PHP process for taking too much load on regenerating image transformations.

The designer of PHP probably took a big load too while creating the first draft.

Are you transforming images on the fly, why not use prepared images?

150 users is not very much so if that causes problems it seems the site does a lot of unnecessary work?

Or am I missing something?

LiipImagine bundle? I once faced the same issue, for me there where 4 "huge" images on the page and as browsers tend to request them at the same time, php was hit with 4 requests per client. Each checking the folder, nah no image found, let's resize it, out of memory, as there are other fpm processes.

I since added the creation of these images to my release process.

Not sure but if you have full controll over the server, you could try imagemagik instead of gd, as gd tends to stay within php memory limits, while imagik doesn't (not sure though, the last time I used imagik was in 2014)

Oh, and about php, it was originally designed only as a html templating engine for c

@Voxera The CMS creates transformations and stores them in a runtime folder if they don't exist yet (checks with every HTTP request).
In this website's case the deleted folder contained about 1000 transfomations and because of many visitors it was too much to transform at once.

@Wack Yep, that's what happened.
Good point! I should check that out, if I can add a release trigger script to create all transformations.
And probably enable maintenance mode as well next time in prod 😅

@PonySlaystation are all created at once or on demand?

It should transform on demand and use a cron job for heavy batch transformations.

@Voxera they are created on demand, issue is, that let's say on a single page are 10 images, so one page request will spawn 10 resize requests. If the images are big 10 (more or less) simultaniously resizes will trigger the memory limit of php -> pain.

@Wack do you need so big images or could you enforce a smaller image to begin with. Or possibly pre create one or two intermediate sizes on upload.

Another option would to put images on another platform that not have php’s limits or that can serialize them partly but that depends on the economics of cause.

And it you run on your own server or just hosted php site.

@Voxera Good point.
I think if we get another project like this, I'll have to make a batch process to generate all transformations before release.
New images on single articles after release will not be a problem.

We have in most cases used standard PHP hostings from our trusted hosting provider, but we're also thinking about renting a managed/unmanaged root server, which we could use as well for NodeJS things.

On what kind of hostings do you release your web applications/websites?

Usually they could be resized, in my case I didn't think of resizing them when uploaded, enter maketing, who uploads 6000px wide hires stock images...

I've then implemented a resizing to max 2000px width on upload and since imagine bundle has console commands, it's pretty straight forward to create a command, fetching all articles/etc. On the front/heavy traffic/image page and resize them on cli, at release time (php usually doesn't have a memory limit on cli)

@PonySlaystation at work we have 1 and 1/3 rack of servers ;) and we build subscription services. So we never develop specifically for a customer and our oldest product is over 15 years by now.

So its quite a bit different, especially performance vice.

With up to a couple of hundred thousand visitors in a busy day we use clustered webservers and databases along with dedicated cache servers and background task servers.

But I used to build a few things in php but we hosted on out own servers.

My few privet projects reside in two vps instances I rent privately.