php5-fpm configuration pm - (node) Process manager settings nodes in more layman terms

I have the following configuration for php-fpm

[www]
listen = 127.0.0.1:9000
listen.allowed_clients = 127.0.0.1
user = www-data
group = www-data
pm = dynamic
pm.max_children = 50
pm.start_servers = 25
pm.min_spare_servers = 5
pm.max_spare_servers = 35
pm.max_requests = 2500
pm.status_path = /php-status

I read this documentation page.

Would appreciate a more human explanation of the pm related settings.

For exampel, what is pm = dynamic ? are there other possible settings for pm = ? pm.max_children sets the limit on the number of simultaneous requests that will be served.

so does that mean if I have 51 different visitors, the php-fpm cannot handle the 51st visitor to the website?

What happens then? Does the 51st visitor get a 404?

I am more dev than ops, so would appreciate a more human explanation.

Solution 1:

There are two types of processor management (PM). dynamic and static.

Static

The static method is very simple. You have a set number of children and php-fpm will always try to maintain that number of children. So, if you set pm=static and pm.max_children = 50, you will always have 50 children, no matter what.

This is good if you have very consistent and well measured traffic. This prevents wasting effort growing and shrinking workers (minimal impact w.r.t dynamic). It also reduces unpredictability. Save CPU

All other fields are unused if set to static.

Dynamic

Dynamic allows your children count to fluctuate. It's easier to understand with example as we go.

When the server boots, it starts at pm.start_servers. We now have 25 by your example. Let's say 20 of them are being used and another request has come through, then it's served but your child count increases by 1 as it has met the minimum spare threshold. Remember, creating process is time consuming, so you want to handle it with a process that's already active. Let's say the load increases more and now you have 49 active children. Then up to 50 are made because that's your maximum. Now let's say your load decreases and there are 14 active ones. Then it'll unload one child to reach total of 49 children as it meets your maximum spare servers. If your load goes down further to zero, you will have 35 children and you'll never be able to go below 35 (with exception of via max requests, see below). Children count are reduced so you get more usable ram back.

Dynamic is a bit of a "don't worry, I'll optimize for you within limits".

This is good if you need to keep memory low. Save RAM

Requests over max

If you have 50 active and get another request, it'll likely go in queue by the manager. Though uncertain, I think it also tends to reject if the queue length is ridiculously long. If it stays in queue for too long, the requester, like nginx, will return 504 to the end user as gateway has timed out. To avoid something like all requests being timed out due to endless congestion (ddos?), nginx typically stops passing load to a dead server for a period of time defined in nginx (completely guessing around 30 seconds) once it reached a certain number of errors from the backend.

Max Requests

The pm.max_requests value defines how many requests a child should handle before destroying itself for a new process to take it's place (or nothing if still within the limits of the current dynamic status as defined above). This helps fight against memory leaks (either in php-fpm child itself or your application). So, if there was a memory leak, the memory usage of the child will keep going up. Why it keeps going up even after php execution completes and all that is how php-fpm optimizes its processes and stuff... I feel like that's a separate essay.

To note for prevention of confusion indicated by your post (or lack of clarity). This has NOTHING to do with how many visitors you have or even how many people are viewing your site right now. It's all about how many php we are processing simultaneously. You'd expect most processes to complete in under 300ms. Under 100ms as ideal in personal opinion. With a better hardware, you can process more quickly, so you can handle more visitors (or more precisely, requests) despite no change in simultaneous process count.

P.S. All I said here applies to apache as well. Just different variable names.