Memory limit on php.ini seems not updated when container size is updated

[brandon-welsch]

Problem

When changing the container size, the memory limit in php.ini is not changed automatically.
This causes the container to use a much lower memory limit while the container has more memory and that PHP could use more memory.

See: https://github.com/Scalingo/php-buildpack/blob/master/conf/php/php.ini#L15

Related intercom conversation: https://app.intercom.com/a/apps/w4oogu7s/inbox/inbox/3379738/conversations/12375700056080

[brandon-welsch]

Another customer impacted by this issue: https://app.intercom.com/a/apps/w4oogu7s/inbox/inbox/3379738/conversations/12375700056305

[Soulou]

The idea is that a bigger container type could be used to receive more requests. Note that the person can update its configuration throught customer composer.json parameters.

But indeed maybe we could make this value a little bit more increasing. But it should not be ×2 per type of container, I don't think it's a good idea.

[EtienneM]

I'm not sure I understand why the value of this parameter should be set to something lower than the available memory in the container. But if you think it's important that it's not set to all the memory available, what would be a good value?

Its value is currently 196 MiB. It's 75% of a S container. Should we always set it to 75% of the available memory?

[Soulou]

Actually this value is the memory limit Per Request not for the global PHP consumption.

The memory model of PHP is working that way, each request is isolated in it's own process (process managed in a pool of processes by PHP-FPM in our case).

The memory_limit parameter defines how much a single process can use.

I think that we set a default of 196MiB because otherwise some symfony or other frameworks requests won't even work in a container of size S. I think it was define as the "bottom required memory for most PHP app".

Having 392MiB per request or even 784MiB per request is like quite point less, it just allow failing logics to have more impacts on the application as the PHP process won't stop the request saying "you take too much memory", but will allocate it and eventually swap and slow down the whole application.

My proposal is more to have a growth factor which is more relative.

196MB S/M
and then × 1.25 or something like this for bigger container types, as actually indeed L/XL containers tend to host larger applications than S/M. but I don't see any sense in putting a super large memory_limit except increasing the risk of crashing/slowing down the whole app when 1 specific request is abusing.