Fine tuning PHP-FPM

PHP-FPM Process Management

PHP is the most commonly used backend language for building websites on the planet. PHP-FPM has become the most performant way to run PHP, so let’s look at fine tuning the process management.

So there are three ways to configure the process management (pm) in php-fpm. We have dynamic, ondemand and static.

Let’s take a look at our server, and apply a rather clumsy but efficient analogy of running a busy restaurant.

Restaurant Anology

On Demand

First up we have our ondemand setting, this would be like running a restaurant and setting up a new seating area for each customer as they arrive and hoping there’s enough room to fit the next customer in.

It might sound crazy, but if you’re not expecting much foot traffic then think of the floor space that frees up for other applications.

Useful for: Low traffic site

You can think of ondemand as being the aggressive option. No child processes are created at startup, they will be created when new requests will connect. It will also despawn processes once they’re not needed and free up memory for the rest of the server. This can be useful if you know your site won’t get much traffic or have infrequent load, for instance staging servers or admin panels.

Here are the variables you will need to configure after this has been selected:

pm.max_children           - the maximum number of children that
                            can be alive at the same time.
pm.process_idle_timeout   - The number of seconds after which
                            an idle process will be killed.

Dynamic

Next up we have our dynamic setting. This is like having all the chairs and tables set up in our restaurant ready to serve customers, but also having some extra chairs in storage for when we’re too busy and need extra capacity during the holiday season.

Useful for: Medium traffic site / shared resources.

So with pm dynamic, the child processes are set dynamically. You specify how many you want upfront, the minimum number of spare processes, and the maximum number of spare processes.

This will then stop workers depending on the number of idle processes amongst them. Essentially dynamic is the middle ground option, and likely the best compromise between speed and memory usage.

Here are the variables you will need to configure after this has been selected:

pm.max_children      - the maximum number of children that can
                        be alive at the same time.
pm.start_servers     - the number of children created on startup.
pm.min_spare_servers - the minimum number of children in 'idle'
                        state (waiting to process). If the number
                        of 'idle' processes is less than this
                        number then some children will be created.
pm.max_spare_servers - the maximum number of children in 'idle'
                        state (waiting to process). If the number
                        of 'idle' processes is greater than this
                        number then some children will be killed

Static

Lastly we have our static setting. This is great for a busy restaurant, when we know we want to maximise the seating area ahead of time. We’re not sharing the floor space with other restaurants, and we don’t want to waste resources adding and removing seating.

Useful for: High traffic site / single website servers

If you’re running a performant site, then you want to have child processes ready to serve that traffic. So static ensures a fixed number of child processes are always available to handle user requests. This is set by pm.max_children

So if you know how many requests this box needs to serve, the memory consumption is consistent then you can preallocate these ahead of time. So while it does keep ahold of that memory, it will also help stop php-fpm absorbing more memory than you want it to.

Here is the only variable you will need to configure after this has been selected:

static  - a fixed number (pm.max_children) of child processes;

Pools

Now this is where the anology breaks down. PHP-FPM comes with the concept of pools. So each website could have it’s own resource requirements. Infact, you can actually use different pools for different parts of your website, so you can mix and match the above process management strategies.

So your admin panel might be low traffic, but have high memory requirements. Whereas your frontend might use a little memory, but have a lot of traffic. So ondemand might be the right choice for your admin panel, and static might be the right choice for your frontend.

You can configure nginx to use different pools based on the URL by using the fastcgi_param parameter in your nginx file.

Summary

As with everything in tech, there’s no one size fits all approach to fine tuning. Hopefully this gives you a greater insight into which strategy might be right for your business.

If in doubt, you can launch a like-for-like staging server and mock your traffic with a mixture of frontend and load impact tests.