Optimizing worker_processes, worker_connections & PHP_FCGI_CHILDREN - Any Good Tutorial?

[Reinis Rozitis]

>> The basic approach usually as far as I know is to set worker_processes 
>> based
>> on your CPU core count (either identical or sometimes there is benefit
>> setting with some multiplier - 2*cores (I have seen some improvements 
>> when
>> using nginx as on-the-fly image resizer to utilise the box more)).
>>
>> worker_connection - typical 1024 or 2048 usually is enough. Bassically 
>> the
>> math is based on max_clients where: max_clients = worker_processes *
>> worker_connections
>
> this is right only if your webserver is ONLY serving dynamic content
> without caching. If nginx is serving static file or dynamic content
> from cache, you will have less connections to the fcgi backend than
> you have incoming connections on the web server. There is no way to
> know exactly how many fcgi concurent connexions. You can set
> max_children depending on your RAM.

Nginx has a quite small memory footprint (if you dont go overboard with 
buffers per connection).
And you can have thousands of open connections because of effective event 
models (especially when using it for comet-type applications) and still not 
consuming much memory.

For nginx-type server maximum clients doesnt mean the same as for apache 
MaxClients which could result in the same number as httpd processes running 
(each with php module loaded) consuming loads of memory so you had to be 
extra carefull with that setting otherways things could turn ugly.

The beauty about php in fastcgi mode is the controlled memory consumption 
(besides the typical leaking in php/extensions - which is "fixed" by 
periodically restarting the childs (done by the master php process)) - it 
doesnt really change/jump - eg you set 10 startup childs which easily can 
handle more than just 10 users as nginx makes a queue and will pass the 
requests to the php fcgi backend (of course if you are running php code like 
<? sleep(60); ?> then only 10 clients at time (minute) will be processed for 
dynamic content).



In short max_clients/worker_connections are only loosely related (it doesnt 
matter if thats a static or dynamic request - all go into the same worker 
threads (there is a bit difference if you make a lot of backend 
connections/proxying)) to amount of php processes in a world of nginx-type 
servers.

And in case you use FPM even the variable PHP_FCGI_CHILDREN has become 
deprecated as the new syntax for process management is something like:

pm = dynamic
pm.max_children = 70
pm.start_servers = 20
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 1000



p.s. afaik the only thing which the php-dev team havent still implemented is 
the FCGI_OVERLOADED (according to fcgi spec) feature..  to let the webserver 
know sooner that there aren't enough resources on the backend to process the 
request rather than after timeouts.

rr