Optimizing worker_processes, worker_connections & PHP_FCGI_CHILDREN - Any Good Tutorial?

[Jérôme Loyet]

2010/6/15 Reinis Rozitis <r at roze.lv>:
>>> 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

make pm.start_servers greater than pm.min_spare_servers and lower than
pm.max_spare_servers
because at startup, if no connection arrives and if start_servers is
lower than min_spare_servers fpm will kill one process per second
until current process count reaches min_spare_servers.

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

interesting. Does nginx handle this fcgi response ? You can open a bug
on bugs.php.net to request this feature and, if you have so, propose a
corresponding patch.