# FPM is available in a separate SVN branch - Thread: https://externals.io/message/46277 - Original archive: https://news-web.php.net/php.internals/46277 - Started by Antony Dovgal on 2009-12-04T12:53:52+00:00 - Messages: 32 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/46277.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #46277 — Antony Dovgal — 2009-12-04T12:53:52+00:00 URL: https://externals.io/message/46277#46277 Hello all. I'm glad to announce that we now have FPM SAPI available for testing in a separate SVN branch. You can check out its sources using the following command: svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm Building FPM is as easy as `./configure --enable-fpm && make install`. After that you need to adjust the default config file (installed into $prefix/etc) and run `php-fpm`. For those who don't know what FPM is: FPM (FastCGI Process Manager) is an alternative PHP FastCGI implementation with some additional features useful for heavy-loaded sites. These features include: - advanced process management with graceful stop/start; - ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode); - stdout & stderr logging; - emergency restart in case of accidental opcode cache destruction; - accelerated upload support; - "slowlog"; - fastcgi_finish_request() - special function to finish request & flush all data while continuing to do something time-consuming (video converting, stats processing etc.); and some more. You are welcome to test the code and report any issues to me (since it's not fully official, we don't have a category @ bugs.php.net yet). -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP --- ## #46278 — Jordi Boggiano — 2009-12-04T13:42:32+00:00 URL: https://externals.io/message/46277#46278 · In reply to: #46277 > - advanced process management with graceful stop/start; > - ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode); > - stdout & stderr logging; > - emergency restart in case of accidental opcode cache destruction; > - accelerated upload support; > - "slowlog"; > - fastcgi_finish_request() - special function to finish request & flush all data while > continuing to do something time-consuming (video converting, stats processing etc.); > and some more. Most awesome features, seems like it allows you to easily skip all the *suexec stuff too to build a multi-user hosting environment. Thanks a lot to you and whoever was involved in this, I hope I can manage to try this soon. Cheers, Jordi --- ## #46279 — johannes@schlueters.de — 2009-12-04T13:58:18+00:00 URL: https://externals.io/message/46277#46279 · In reply to: #46277 > Hello all. > > I'm glad to announce that we now have FPM SAPI available for testing in a separate SVN branch. > > You can check out its sources using the following command: > svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm How big would be the impact in regards to BC and stuff for merging it back in 5_3? If i read the svn log correct it's just a SAPI ... so adding it might be low risk as it only affects people using it. Is it related to the CGI SAPI codewise? If yes: would there be plans to merge it in some way or would we have to fix bugs in CGI, FPM and probably CLI which all have the same roots? johannes --- ## #46280 — Antony Dovgal — 2009-12-04T14:07:03+00:00 URL: https://externals.io/message/46277#46280 · In reply to: #46279 > How big would be the impact in regards to BC and stuff for merging it > back in 5_3? If i read the svn log correct it's just a SAPI ... so > adding it might be low risk as it only affects people using it. That's right, it's a separate SAPI, it doesn't affect anything beyond sapi/fpm in any way. > Is it related to the CGI SAPI codewise? Yes, it uses modified versions of cgi_main.c and fastcgi.c/.h. > If yes: would there be plans to > merge it in some way or would we have to fix bugs in CGI, FPM and > probably CLI which all have the same roots? I'm planning to remove some more unused/unnecessary code from fpm_main.c. I guess this will somewhat reduce the amount of porting between the "copy" and original file. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP --- ## #46281 — Stanislav Malyshev — 2009-12-04T21:18:42+00:00 URL: https://externals.io/message/46277#46281 · In reply to: #46277 Hi! > You can check out its sources using the following command: > svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm Just curious - any plans for win32 support? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #46283 — Michael Shadle — 2009-12-05T00:25:58+00:00 URL: https://externals.io/message/46277#46283 · In reply to: #46277 Antony - thank you so much! This is quite a surprise though, I didn't know there were plans for this... I was talking to gwynne on IRC about the best way to get this going. I suppose it being a separate SAPI works, but I had also thought: "What if it was just a modification to the FCGI SAPI, and the FPM management features, config file parsing, all that were in a standalone daemon. That allows for a lot of changes and such to be done in the daemon portion without having to align it with PHP releases" I don't think a lot has to be done really to the internals once the portions you've listed before were adopted. Only a few IPC, socket or command line options to start/stop from an external daemon would need to be involved, and communication to allow for adaptive process spawning... We've been wanting to change the configuration file syntax already and the majority of "wishlist" items we've wanted to add mainly fall under the manager daemon... I am just scared that it may take a while for those to be released if it has to fall under PHP's release cycle (not to mention do other SAPIs have their own configuration files and such? Seems like an awful lot of 'special needs' is now bundled in to a SAPI inside of PHP core) Either way though - this is a win. I was unaware this was even happening. We've been having discussions on the php-fpm mailing list about this and a little bit of internal battling on it too (mainly 100% php core vs. only the portions needed in php core, etc.) This is awesome though. Hopefully we can get things moving faster. If anyone is interested in the ideas we have to make things easier to use and enhance some functionality *please* don't hesitate to email me off list. I have a feeling the majority of items aren't actually that difficult. > Hello all. > > I'm glad to announce that we now have FPM SAPI available for testing in a separate SVN branch. > > You can check out its sources using the following command: > svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm > > Building FPM is as easy as `./configure --enable-fpm && make install`. > After that you need to adjust the default config file (installed into $prefix/etc) > and run `php-fpm`. > > > For those who don't know what FPM is: FPM (FastCGI Process Manager) is an alternative > PHP FastCGI implementation with some additional features useful for heavy-loaded sites. > These features include: > - advanced process management with graceful stop/start; > - ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode); > - stdout & stderr logging; > - emergency restart in case of accidental opcode cache destruction; > - accelerated upload support; > - "slowlog"; > - fastcgi_finish_request() - special function to finish request & flush all data while > continuing to do something time-consuming (video converting, stats processing etc.); > and some more. > > You are welcome to test the code and report any issues to me (since it's not fully official, > we don't have a category @ bugs.php.net yet). > > -- > Wbr, > Antony Dovgal > --- > http://pinba.org - realtime statistics for PHP --- ## #46284 — Michael Shadle — 2009-12-05T00:40:04+00:00 URL: https://externals.io/message/46277#46284 · In reply to: #46277 what version of PHP-FPM code is this based off of? the latest 0.6.x at launchpad or one of the older patches? we have had reports of some issues with php 5.3.x and php-fpm 0.6.x. Andrei had changed the code from being a patch to being a standalone daemon that builds against vanilla php sources for the "new" 0.6.x generation. Just want to know when in the timeline you pulled the code from so we can ask people to test the bugs they reported against it to see if it's still a bug. > Hello all. > > I'm glad to announce that we now have FPM SAPI available for testing in a separate SVN branch. > > You can check out its sources using the following command: > svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm > > Building FPM is as easy as `./configure --enable-fpm && make install`. > After that you need to adjust the default config file (installed into $prefix/etc) > and run `php-fpm`. > > > For those who don't know what FPM is: FPM (FastCGI Process Manager) is an alternative > PHP FastCGI implementation with some additional features useful for heavy-loaded sites. > These features include: > - advanced process management with graceful stop/start; > - ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode); > - stdout & stderr logging; > - emergency restart in case of accidental opcode cache destruction; > - accelerated upload support; > - "slowlog"; > - fastcgi_finish_request() - special function to finish request & flush all data while > continuing to do something time-consuming (video converting, stats processing etc.); > and some more. > > You are welcome to test the code and report any issues to me (since it's not fully official, > we don't have a category @ bugs.php.net yet). > > -- > Wbr, > Antony Dovgal > --- > http://pinba.org - realtime statistics for PHP --- ## #46290 — Antony Dovgal — 2009-12-07T09:21:28+00:00 URL: https://externals.io/message/46277#46290 · In reply to: #46281 > Hi! > > > […] > > Just curious - any plans for win32 support? If you want to work on it - sure, no problem. But you know me, I have neither knowledge nor desire to work on it myself. Also a heavy loaded server on Windows is something out of this world to me. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP --- ## #46291 — Antony Dovgal — 2009-12-07T09:25:51+00:00 URL: https://externals.io/message/46277#46291 · In reply to: #46283 > "What if it was just a modification to the FCGI SAPI, and the FPM > management features, config file parsing, all that were in a > standalone daemon. That allows for a lot of changes and such to be > done in the daemon portion without having to align it with PHP > releases" That's the thing I want to avoid, actually. Moving something out of PHP just because you're afraid of its release cycles means you make it harder to maintain, not easier. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP --- ## #46293 — jerome@loyet.net — 2009-12-07T09:30:32+00:00 URL: https://externals.io/message/46277#46293 · In reply to: #46290 2009/12/7 Antony Dovgal : > > > […] Hi tony, I've been working on php-fpm. If I want to submit patches, what is the best way to do it ? ++ jerome --- ## #46295 — Pierre Joye — 2009-12-07T09:40:10+00:00 URL: https://externals.io/message/46277#46295 · In reply to: #46281 hi! > Hi! > > > […] > > Just curious - any plans for win32 support? I remember some discussions about it but I did not follow the recent developments. We can take a look at a possible port once it is "ready" (when Antony is done with the cleanup). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #46297 — Michael Shadle — 2009-12-07T10:01:38+00:00 URL: https://externals.io/message/46277#46297 · In reply to: #46291 > That's the thing I want to avoid, actually. > Moving something out of PHP just because you're afraid of its release cycles > means you make it harder to maintain, not easier. Even if it is just the management component of it? Any of the PHP internals will still stay inside of PHP. It will only be the daemon portion that tells the new SAPI how to behave (spawn more under this pool, kill this child, do that?) etc? --- ## #46298 — Michael Shadle — 2009-12-07T11:35:53+00:00 URL: https://externals.io/message/46277#46298 · In reply to: #46297 > > > > […] > > Even if it is just the management component of it? > > Any of the PHP internals will still stay inside of PHP. It will only > be the daemon portion that tells the new SAPI how to behave (spawn > more under this pool, kill this child, do that?) etc? Or, perhaps move it into PECL at least? There are still many things TBD in PHP-FPM, one of them was a discussion about possibly changing the model to make it more accommodating for shared hosting providers. Other features grokked from the wishlist/would be logged as "feature requests" when I had setup the bug tracker: - Adaptive process support (the major thing lacking) - CPU affinity/load balancing - Config file syntax change - Syslog support - Per-pool php.ini file (should be easy) - See if the normal libevent or libev could handle all the needs and not a patched copy anymore (or get with the libevent team) - Metrics/reporting, possibly like postfix's anvil reports out, or a way to query the SAPI to get an idea of usage At the moment unless these changes are ready for commitment into a PHP beta build they won't get out until the next one, and so on... at least with PECL there is a clear delineation from core. Anyway, as acting manager for the project I really would like to be able to figure out the future - what we should be doing on the side (obviously trying to work on code and submit it when ready) but do we still maintain the documentation, or will it migrate to php.net then? Since the SAPI includes the config file, now all of a sudden that becomes thrown under the PHP core umbrella for documentation, and the existing XML configuration (and desired nginx style configuration) both do not line up with the INI style configuration that PHP users are used to. This might be one of the main reasons why I think having the daemon/management portion be split out. Otherwise, if it is part of core, then core has to have pages with documentation for all of this as well, bug tracking for it, etc. Quite possibly, if split apart, a better management daemon or tool would be developed as well, as the API would be in place to manage the FPM SAPI'ed PHP processes from an external manager. (Heck, do I see control panel integration points? cpanel/plesk/etc. could now define PHP process quotas per user for example?) Just spitballing here. You're ultimately the master of this domain. I also don't want to spam the list. I'm more than happy to pro/con this offline with you. Or have you tell me flat out what I should be changing on the community side of things. "Keep your own svn, but keep it in sync with our branch. Once a feature is complete and assumed bug free, then send the patch to us" or "Use php.net for the bugtracker now, there is no need for an external website anymore either. Documentation will also be hosted on php.net as well" ... etc. --- ## #46299 — Reinis Rozitis — 2009-12-07T13:30:07+00:00 URL: https://externals.io/message/46277#46299 · In reply to: #46298 > - See if the normal libevent or libev could handle all the needs and > not a patched copy anymore (or get with the libevent team) Isn't this is allready done since 0.6.x fpm? Afaik php-fpm needs external libevent on system now. > - Adaptive process support (the major thing lacking) Somewhat done with the 'apache-like' spawning mechanism? rr --- ## #46307 — jerome@loyet.net — 2009-12-07T13:57:02+00:00 URL: https://externals.io/message/46277#46307 · In reply to: #46299 2009/12/7 Reinis Rozitis : > > […] > > Isn't this is allready done since 0.6.x fpm? Afaik php-fpm needs external > libevent on system now. there is no more patch libevent, it's dependent of official libevent. It's all ok. > > > […] > > Somewhat done with the 'apache-like' spawning mechanism? As far as I know nohting has been done about adaptive process support or 'apache-like' spawning mechanism. It's been present in conf file without being supported. > > rr --- ## #46317 — jerome@loyet.net — 2009-12-07T14:41:34+00:00 URL: https://externals.io/message/46277#46317 · In reply to: #46298 2009/12/7 Michael Shadle : > > > […] > Before integration of php-fpm in the official php tree I agreed with you about separating daemon stuff out of php tree and include only necessary functions (communication about spawning, chroot, ...) in php-fastcgi (cgi sapi). But as it's been totaly included as an independant sapi, I don't see any benefit to split. The fpm sapi would be only a patch version of the cgi sapi in order to work exclusively with an external software. This is illogical to me. And as tony has worked on this integration it would be a waste of time to change this. I hear you concerns about frequency of releases. Why don't follow patch against official release on the php-fpm website or something like that ? We have some thinking to do to find a solution that pleases everyone. > Or, perhaps move it into PECL at least? What PECL can help here ? Is PECL just a compiled packages library for PHP ? > > There are still many things TBD in PHP-FPM, one of them was a > discussion about possibly changing the model to make it more > accommodating for shared hosting providers. > > Other features grokked from the wishlist/would be logged as "feature > requests" when I had setup the bug tracker: > - Adaptive process support (the major thing lacking) > - CPU affinity/load balancing > - Config file syntax change > - Syslog support > - Per-pool php.ini file (should be easy) > - See if the normal libevent or libev could handle all the needs and > not a patched copy anymore (or get with the libevent team) > - Metrics/reporting, possibly like postfix's anvil reports out, or a > way to query the SAPI to get an idea of usage > > At the moment unless these changes are ready for commitment into a PHP > beta build they won't get out until the next one, and so on... at > least with PECL there is a clear delineation from core. > > Anyway, as acting manager for the project I really would like to be > able to figure out the future - what we should be doing on the side > (obviously trying to work on code and submit it when ready) but do we > still maintain the documentation, or will it migrate to php.net then? > Since the SAPI includes the config file, now all of a sudden that > becomes thrown under the PHP core umbrella for documentation, and the > existing XML configuration (and desired nginx style configuration) > both do not line up with the INI style configuration that PHP users > are used to. > > This might be one of the main reasons why I think having the > daemon/management portion be split out. Otherwise, if it is part of > core, then core has to have pages with documentation for all of this > as well, bug tracking for it, etc. Quite possibly, if split apart, a > better management daemon or tool would be developed as well, as the > API would be in place to manage the FPM SAPI'ed PHP processes from an > external manager. (Heck, do I see control panel integration points? > cpanel/plesk/etc. could now define PHP process quotas per user for > example?) > > Just spitballing here. You're ultimately the master of this domain. I > also don't want to spam the list. I'm more than happy to pro/con this > offline with you. Or have you tell me flat out what I should be > changing on the community side of things. "Keep your own svn, but keep > it in sync with our branch. Once a feature is complete and assumed bug > free, then send the patch to us" or "Use php.net for the bugtracker > now, there is no need for an external website anymore either. > Documentation will also be hosted on php.net as well" ... etc. --- ## #46330 — Michael Shadle — 2009-12-07T17:47:43+00:00 URL: https://externals.io/message/46277#46330 · In reply to: #46307 Sent from my iPhone > 2009/12/7 Reinis Rozitis : > > […] > > there is no more patch libevent, it's dependent of official libevent. > It's all ok. Shows how much I know. I haven't used 0.6.x yet because all my build scripts worked flawlessly with the patch. > > > […] > > As far as I know nohting has been done about adaptive process support > or 'apache-like' spawning mechanism. It's been present in conf file > without being supported. Correct. Biggest lacking feature. > > > […] --- ## #46332 — Reinis Rozitis — 2009-12-07T18:26:18+00:00 URL: https://externals.io/message/46277#46332 · In reply to: #46330 > Correct. Biggest lacking feature. While this maybe a bit out of topic, but just out of curiosity why do you think that adaptive spawning is any good (trying to run more processes in given time period than started) - "stepping" back to how apache operates with its prefork mechanism (iirc there are even people from php-dev community which suggested running apache with start/maxservers identical so there is always constant number of childs (for php processing) to avoid unwanted/unexpected resource consumption? There should be reasons why it was also dropped from the other external process manager lighty/spawn-fcgi and never planned in webservers like nginx .. I would rather want to see one day php (master process) return FCGI_OVERLOADED for the webserver/application to decide what to do next. rr --- ## #46334 — Stanislav Malyshev — 2009-12-07T18:49:03+00:00 URL: https://externals.io/message/46277#46334 · In reply to: #46290 Hi! Couple of other notes here: 1. I understand this SAPI uses its own XML config format. While it is not unheard of for SAPIs to integrate into external servers and thus have diferent config ways, this one is self contained - so I wonder if it would be possible to make it configured by .ini? We have .ini parser, people know what .ini format is, etc. 2. Do we need if we already have user ini files? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #46335 — Michael Shadle — 2009-12-07T19:11:05+00:00 URL: https://externals.io/message/46277#46335 · In reply to: #46334 For #2 it might no longer be needed that might be up for debate. It's nice to be able to override a single option. But 5.3 with it's htaccess/htscanner behavior might work good enough for most things (but PHP_INI_SYSTEM might be still nice to override one offs instead of having to point to a totally separate ini file) unless you say that there is a global ini file with defaults and the per-pool override is just overrides for that. As for #1 we are working on changing the config file syntax and the idea was to make it use nginx style. I don't think it will fit in ini file format as it needs arrays or some sort of n+1 group structure support/nested options. IIRC array support did just get inplemented in 5.3 did it not? That - may- be an option then. Then fpm could actually share php.ini itself. I guess it depends on if the ini support php has will work well with nested groupings. Sent from my iPhone > Hi! > > Couple of other notes here: > > 1. I understand this SAPI uses its own XML config format. While it > is not unheard of for SAPIs to integrate into external servers and > thus have diferent config ways, this one is self contained - so I > wonder if it would be possible to make it configured by .ini? We > have .ini parser, people know what .ini format is, etc. > > 2. Do we need if we already have user ini > files? > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com --- ## #46336 — Michael Shadle — 2009-12-07T19:13:33+00:00 URL: https://externals.io/message/46277#46336 · In reply to: #46332 The problem with running a static amount of processes is trying to figure out the right number. Also it is not elastic in any fashion. Shared hosts would love the elasticity as it will allow sites to flex up and down as needed without giving each individual user more processes than they really need A global max amount of processes or memory consumption metric might be useful to throttle the entire daemon from spawning new children. Sent from my iPhone > > […] > > While this maybe a bit out of topic, but just out of curiosity why > do you think that adaptive spawning is any good (trying to run more > processes in given time period than started) - "stepping" back to > how apache operates with its prefork mechanism (iirc there are even > people from php-dev community which suggested running apache with > start/maxservers identical so there is always constant number of > childs (for php processing) to avoid unwanted/unexpected resource > consumption? > > There should be reasons why it was also dropped from the other > external process manager lighty/spawn-fcgi and never planned in > webservers like nginx .. > > > I would rather want to see one day php (master process) return > FCGI_OVERLOADED for the webserver/application to decide what to do > next. > > rr --- ## #46343 — Stanislav Malyshev — 2009-12-07T19:58:45+00:00 URL: https://externals.io/message/46277#46343 · In reply to: #46335 Hi! > As for #1 we are working on changing the config file syntax and the idea > was to make it use nginx style. I don't think it will fit in ini file > format as it needs arrays or some sort of n+1 group structure > support/nested options. Nesting can be done by name, and .ini can do arrays. See here: http://php.net/parse_ini_file and also here: http://framework.zend.com/manual/en/zend.config.adapters.ini.html for how you can do stuff with .ini's :) > IIRC array support did just get inplemented in 5.3 did it not? That > -may- be an option then. Then fpm could actually share php.ini itself. [] was working in 5.2 too. 5.3 can do indexes. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #46345 — jerome@loyet.net — 2009-12-07T20:16:22+00:00 URL: https://externals.io/message/46277#46345 · In reply to: #46343 2009/12/7 Stanislav Malyshev : > Hi! > > > […] > > Nesting can be done by name, and .ini can do arrays. See here: > http://php.net/parse_ini_file > and also here: > http://framework.zend.com/manual/en/zend.config.adapters.ini.html > for how you can do stuff with .ini's :) > > > […] Yes INI is natively handled in PHP (and adding the missing include function is easy) and I already did it. But the syntax is not that good for php-fpm, try to configure apache, tomcat or nginx with INI syntax ... it's a pain in the ass as xml is. Despite all that, php-fpm aim is to run as a standalone daemon which has never been the aim of any sapi before (maybe I'm wrong) and therefore INI syntax has never been used in a such context. Here is en example of nginx syntax and then INI ... I my mind there is no comparaison. pid /var/run/php-fpm.pid; error_log /var/log/php-fpm.log; log_level notice; emergency_restart_threshold 10; emergency_restart_interval 1m; process_control_timeout 5s; daemonize no; worker { name default; listen { address tcp:127.0.0.1:9000; backlog -1; owner nobody; group nogroup; mode 0666; } php_define short_open_tag=On; user nobody; group nogroup; static { max_children 5; } dynamic { max_children 20; StartServers 5; MinSpareServers 5; MaxSpareServers 15; } request_terminate_timeout 0s; request_slowlog_timeout 0s; slowlog /var/log/php-fpm.log.slow; rlimit_files 1024; rlimit_core 0; chroot /usr/local/nginx/html; chdir /; catch_workers_output yes; max_requests 500; allowed_clients 127.0.0.1; env HOSTNAME=$HOSTNAME; env PATH=/usr/local/bin:/usr/bin:/bin; } And the same with ini pid = /var/run/php-fpm.pid error_log = /var/log/php-fpm.log log_level = notice emergency_restart_threshold = 10 emergency_restart_interval = 1m process_control_timeout = 5s daemonize = no worker.name= default; worker.listen.address = tcp:127.0.0.1:9000 worker.listen.backlog = -1 worker.listen.owner = nobody worker.listen.group = nogroup worker.listen.mode = 0666 worker.php_defineshort_open_tag = On worker.user = nobody worker.group = nogroup worker.static.max_children = 5 worker.dynamic.max_children = 20 worker.dynamic.start_servers = 5 worker.dynamic.min_spare_servers = 5 worker.dynamic.max_spare_servers = 15 worker.request_terminate_timeout = 0s worker.request_slowlog_timeout = 0s worker.slowlog = /var/log/php-fpm.log.slow worker.rlimit_files = 1024 worker.rlimit_core = 0 worker.chroot = /usr/local/nginx/html worker.chdir = / worker.catch_workers_output = yes worker.max_requests = 5000 worker.allowed_clients = 127.0.0.1 worker.env.HOSTNAME = $HOSTNAME worker.env.PATH = /usr/local/bin:/usr/bin:/bin > > [] was working in 5.2 too. 5.3 can do indexes. > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com   http://www.zend.com/ > (408)253-8829   MSN: stas@zend.com --- ## #46346 — Stanislav Malyshev — 2009-12-07T20:48:37+00:00 URL: https://externals.io/message/46277#46346 · In reply to: #46345 Hi! > worker.name= default; > worker.listen.address = tcp:127.0.0.1:9000 > worker.listen.backlog = -1 > worker.listen.owner = nobody > worker.listen.group = nogroup > worker.listen.mode = 0666 > worker.php_defineshort_open_tag = On You could also do it as: [WORKER=default] listen.address = tcp:127.0.0.1:9000 ...etc... env["HOSTNAME"]=$HOSTNAME ...etc... -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #46347 — Michael Shadle — 2009-12-08T00:04:12+00:00 URL: https://externals.io/message/46277#46347 · In reply to: #46345 2009/12/7 Jérôme Loyet : so you're saying each worker just has a worker.name prefixed worker.name = pool1 worker.user = nobody worker.group = nogroup worker.static.max_children = 5 worker.dynamic.max_children = 20 worker.dynamic.start_servers = 5 worker.dynamic.min_spare_servers = 5 worker.dynamic.max_spare_servers = 15 ...etc... worker.name = pool2 worker.user = nobody worker.group = nogroup worker.static.max_children = 5 worker.dynamic.max_children = 20 worker.dynamic.start_servers = 5 worker.dynamic.min_spare_servers = 5 worker.dynamic.max_spare_servers = 15 ...etc... not something like worker('pool2').user = nobody worker('pool2').group = nogroup etc? i guess i'm fine with it either was as long as it is easy for end users. also it would be nice to programatically generate it and be able to include it (would require php.ini to have include support. mysql does this with the !include directive, IIRC) --- Next page: https://externals.io/message/46277.md?page=2