Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

http://php-fpm.org/wiki/Configuration_File

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

Eg, 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.

share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

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.

share|improve this answer
    
fantastic answer, boss! Just one question. YOu said, "You'd expect most processes to complete in under 300ms. Under 100ms as ideal in personal opinion." Where can i find this ? I know how to search for the memory usage by each php-fpm process by using top and >. But not too sure how to meansure the completion time for processes –  Kim Stacks Dec 26 '12 at 14:00
    
@kimsia There are many ways to profile php, just google. Profile/profiler/profiling is the keyword(s) you're looking for. –  Grumpy Dec 26 '12 at 14:03
    
thank you, Peter. I did not even know there was such a term called profile php. –  Kim Stacks Dec 26 '12 at 15:57
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.