; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user’s group
; will be used.
user = www-data
group = www-data
A quick look at the end of the snippet above solves the riddle of why the server process runs as www-data. If you’ve come across file permission issues when setting up your website, you’ve likely changed the owner or group of the directory to www-data, thus allowing the PHP process to be able to write into log files and upload documents, etc.
Finally, we arrive at the source of the matter, the process manager (pm) setting. Generally, you’ll see the defaults as something like this:
pm = dynamic pm.max_children = 5 pm.start_servers = 3 pm.min_spare_servers = 2 pm.max_spare_servers = 4 pm.max_requests = 200
So, what does “dynamic” here mean? I think the official docs best explain this (I mean, this should already be part of the file you’re editing, but I’ve reproduced it here just in case it isn’t):
; Choose how the process manager will control the number of child processes. ; Possible Values: ; static - a fixed number (pm.max_children) of child processes; ; dynamic - the number of child processes are set dynamically based on the ; following directives. With this process management, there will be ; always at least 1 children. ; 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. ; ondemand - no children are created at startup. Children will be forked when ; new requests will connect. The following parameter are used: ; 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. ; Note: This value is mandatory.
So, we see that there are three possible values:
- Static: A fixed number of PHP processes will be maintained no matter what.
- Dynamic: We get to specify the minimum and maximum number of processes that
php-fpmwill keep alive at any given point in time. - ondemand: Processes are created and destroyed, well, on-demand.
So, how do these settings matter?
In simple terms, if you have a website with low traffic, the “dynamic” setting is a waste of resources most of the time. Assuming that you have pm.min_spare_servers set to 3, three PHP processes will be created and maintained even when there’s no traffic on the website. In such cases, “ondemand” is a better option, letting the system decide when to launch new processes.
On the other hand, websites that handle large amounts of traffic or must respond quickly will get punished in this setting. Creating a new PHP process, making it part of a pool, and monitoring it, is extra overhead that is best avoided.
Using pm = static fixes the number of child processes, letting maximum system resources to be used in serving the requests rather than managing PHP. If you do go this route, beware that it has its guidelines and pitfalls. A rather dense but highly useful article about it is here.
Final words
Since articles on web performance can spark wars or serve to confuse people, I feel that a few words are in order before we close this article. Performance tuning is as much about guesswork and dark arts as it is system knowledge.
