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



_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx