Input Ideal PHP-FPM Pool Settings for Various Hosting Scenarios

[Mark Bailey]

Hi,

I'm wondering if the Plesk gurus can offer some advice on the best PHP-FPM pool settings for various scenarios:

1. A shared hosting server with domains/subscriptions getting relatively low website traffic (default settings per domain/service plan).
2. A shared hosting server with domains/subscriptions getting moderate to high website traffic (default settings per domain/service plan).
3. A server with only one fairly busy site (server-wide settings and/or specific settings for that domain/subscription).

Of course I know that server resources play a major role here, so I understand that there might be formulas (e.g., setting x = number of CPU cores or RAM divided by setting y). Or, for example, we could use a server with:

• 32 GB RAM
• 4 CPU cores

Any advice will be appreciated!

Thanks,

Mark

 

[ManuelGDot]

Hi Mark,

I might be mistaking but I doubt there's "the ideal" setting for any and all scenarios. That why we have options. You might want to use http/2 and gzip if it's mainly about speed.

I've ran into trouble at machines with only 1GB RAM and FPM but that's not really what your issue is, I believe.

Maybe try to read and understand the difference between FPM and CGI at first. Also FPM-by-NGINX won't work out-of-the-box for your typical Wordpress installation. All combinations have their little pros and cons and foremost: their limitations.

Again, I'm missing the point what you try to achieve. If you need a setting that will work well in most situations, go with the default of Plesk. You may need to increase memory & upload limits in PHP settings but I wouldn't go much further. With an unorthodox configuration chances are that you'll run into trouble much later and won't be able to identify why. With your specs, the real bottlenecks are elsewhere as mentioned before.

Cheers!

 

[websavers]

As ManuelGDot mentioned, it's typically quite difficult to come up with generalized rules that work in a variety of scenarios with different websites. That said, I can tell you what's worked well for us:

A shared hosting server with domains/subscriptions getting relatively low website traffic (default settings per domain/service plan).

The Plesk defaults usually work great for this: ondemand processing.

A shared hosting server with domains/subscriptions getting moderate to high website traffic (default settings per domain/service plan)

We use dynamic processing mode with maybe 5 set processes for min/max. This way the server doesn't need to fork new processes to handle repeated traffic even after a brief lull.

A server with only one fairly busy site (server-wide settings and/or specific settings for that domain/subscription).

Dynamic as well, but you can simply increase the set number of processes based on whether you notice the limit being reached in the logs.

---

Ultimately all of this is also going to depend on how much static file caching you have served by nginx instead. We've got sites with over 100k daily views with full static caching enabled and served by nginx and they're doing fine with just 3 dynamic PHP processes and minimal server resources. It's when the site has repeated calls to dynamic PHP processing (like ajax requests that can't be cached) that the site requires more processing power.

The goal for these optimizations is to limit the number of processes that need to be forked while also not over-forking in advance unless you *want* to simply use all the memory on the box (perfectly reasonable tactic if you've got the resources).

 

[ManuelGDot]

Thanks for sharing more details, @websavers

Just a quick note on that: Please be a bit careful when adjusting the processes, if it's too many these may ultimately hang and you'll have to kill them manually, just be prepared for that. Although that happened to me only on one machine. Still, the real performance benefits won't come just by upping the number of threads, but @websavers explained it much better than I could.

 

[websavers]

Thanks for sharing more details, @websavers

Just a quick note on that: Please be a bit careful when adjusting the processes, if it's too many these may ultimately hang and you'll have to kill them manually, just be prepared for that. Although that happened to me only on one machine. Still, the real performance benefits won't come just by upping the number of threads, but @websavers explained it much better than I could.

Yup, good call. Related to this, if you use dynamic mode it's an excellent plan to set a max requests value -- we often do something between 500 and 1000. That way if there's a memory leak in your web app, it'll eventually kill the process, freeing the memory, then launch a new one to replace it.

 

[Mark Bailey]

Hi all, thanks for the replies!