Separate PHP-FPM process per subscription for security and performance reasons
Sharing a PHP-FPM process with separate pools per websites is a security issue and a problem for performance when some clients may deploy bad scripts to the server.
A huge reason for why sharing the same PHP-FPM process between subscriptions is that the OPCACHE (Xcache, APC and Opcache) share the same memory and it is accessible between clients. Disabling access to stats and controlling api of them is available, but it's not a great solution for some critical cases. Still, this is not suitable when isolation between apps is critical.
Another reason is with php scripts that clients deploy. In some occasions a bad written script can make all Pools dead so all websites become not accessible and 502 error comes continuous (Nginx/Apache gets timeout from the PHP-FPM manager).
Third reason is CGROUPS, to force limitation on CPU and RAM usage, which works great based on services. It's far more easier to implement CGROUPS on separate PHP-FPM managers (check RHEL/CENTOS as they have this implemented in systemd and it's just to apply a custom template to work).
Current implementation of PHP-FPM is great for agencies that just host their clients websites, but it's not great at all for companies that sell hosting.
Madalin Ignisca
shared this idea
Since Plesk Obsidian 18.0.39, published October 13th, 2021, you can select dedicated PHP-FPM handlers for each domain.
-- PD
-
Madalin Ignisca
commented
I'm checking Plesk 17 preview and I found that you've started something for Docker.
As I'm using Docker for some projects and I really love how it is working, I was thinking that Docker would help Plesk become the best Web Hosting Panel among it's competitor if it would implement it in a special way.
I'd love to talk to somebody from Plesk about the idea and some technical stuff related to it.