Andrei has turned the project over to me, and I am trying to keep it
going full steam ahead.
Rasmus told me the only thing stopping it from being adopted into PHP
or PECL was the license. That has now changed.
I don't believe it can be done in PECL, as it needs too many changes
in PHP core.
It would be great if someone would examine the impact of adopting it
as the FastCGI SAPI replacement or looking at what hooks are required
to get it in and perhaps keep the "userland" stuff in PECL...
Thousands of servers run PHP-FPM without a problem - I believe it has
proven to be reliable and safe. I would love to get it moving, and
would also like to keep development on it moving forward. For that, I
have some funds myself and also will be soliciting funds if needed to
keep some of the missing features or enhancements to it going.
However, either on-list or off-list if anyone is interested in
"sponsoring" it and examining it to get it into PHP core, or what it
would take to get into PECL, please, let's keep the dialog open.
For those unaware of what PHP-FPM is, the website has been updated and
is here http://php-fpm.org - it essentially makes FastCGI pool
management extremely easy, removes the need for any sort of suexec,
suphp, custom scripts on top of spawn-fcgi, or other workarounds to
launch pools with different uid/gids, it controls the amount of
children spawned, etc, etc. There's one major feature that never got
completed (adaptive process spawning) and I have a small wishlist of
items I'd be willing to work with a developer to implement. To me, it
is the next stage in helping more people adopt PHP and helps with
security as it won't require a patch to allow them to take advantage
of this capability. (It also enhances the FastCGI SAPI all over,
including forceful termination of processes at a certain configurable
timeout, slow script logging, backtraces on errors, etc...)
Dmitry has shown interest but I think he may be a bit busy to give it
his full attention. If anyone else has spare cycles available I'm more
than happy to work with you!
Thank you!
Hi!
It would be great if someone would examine the impact of adopting it
as the FastCGI SAPI replacement or looking at what hooks are required
to get it in and perhaps keep the "userland" stuff in PECL...
Why it needs to replace existing fcgi SAPI? I would think it is better
to have it just as another SAPI - isn't it possible? I understand
(please correct me if I'm wrong) that php-fpm feature set is different
from what fcgi SAPI now does - php-fpm manages its own processes, etc.
which may be not what some FCGI drivers expect.
I think it is possible to add it as SAPI for HEAD at any time, and once
5.3 is out of the release freeze, add it to 5.3 as well.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
It would be great if someone would examine the impact of adopting it
as the FastCGI SAPI replacement or looking at what hooks are required
to get it in and perhaps keep the "userland" stuff in PECL...Why it needs to replace existing fcgi SAPI? I would think it is better to
have it just as another SAPI - isn't it possible? I understand (please
correct me if I'm wrong) that php-fpm feature set is different from what
fcgi SAPI now does - php-fpm manages its own processes, etc. which may be
not what some FCGI drivers expect.I think it is possible to add it as SAPI for HEAD at any time, and once 5.3
is out of the release freeze, add it to 5.3 as well.Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
I would be more than happy if you would like to do that!
I believe that Dmitry was interested in actually replacing the FastCGI
SAPI with it (or at least patching it 100%) - the configuration options and
"userland" usage of it is where I am not sure how it would "bundle" with PHP
properly. It uses a different config syntax (not ini compatible)
There's 4 options I see:
- Merge it 100% into PHP core (I see some issues with how to configure it
then) - Merge all the core changes required for it to work as a PECL module (so
people can use it via PECL if they wish and configure it how they want, and
all config file syntax changes and such can be done inside of PECL) - Make it 100% PECL (don't think this is possible as it needs too many
things inside of the core of PHP to be changed) - Keep it as a patch (lower adoption, current status quo)
Option #2 might be the best. That will allow for PECL to continue to advance
feature-wise without having to change PHP core. I have a wishlist of ideas
to be implemented and it will be harder if the patch is 100% merged into
PHP.
However, PHP itself does need a handful of things from the patch for PHP-FPM
to work properly. I believe that PHP-FPM can easily be added to the existing
FastCGI SAPI and provide a few extra additions into it, without changing the
existing FastCGI SAPI's behavior. But the hooks need to be put into place so
the PECL module can take advantage of it.
I will help facilitate whatever needs to get done to make this happen.
Anyone who would like to examine it feel free to grab the 5.2.10 patch and
examine it. There hasn't been one produced for 5.3.0 since a much earlier
cvs snapshot, so I would ignore that one.
Taking what is required out of 5.2.10 and baking it in to PHP and then
helping get a PECL module going would probably be the best route to go,
assuming a PECL module can do things such as terminate errant requests based
on configuration options, launch php-cgi processes (essentially), being
started from root, etc.
If funds are required, feel free to shoot me a number. I will try to drum up
what is required to push this through.
This is my wishlist (which in turn would be great to turn in to a roadmap,
just so you know)
http://php-fpm.org/Wishlist
Having some sort of reporting mechanism would be great. The fastcgi.txt file
I reference as well was a rough idea I came up with before knowing about
PHP-FPM, and some of the threshhold warning messages and such would be great
to have too.
Hi!
I believe that Dmitry was interested in actually replacing the FastCGI
SAPI with it (or at least patching it 100%) - the configuration options
and "userland" usage of it is where I am not sure how it would "bundle"
with PHP properly. It uses a different config syntax (not ini compatible)
Well, current fcgi doesn't have too many ini values.
- Merge it 100% into PHP core (I see some issues with how to configure
it then)- Merge all the core changes required for it to work as a PECL module
(so people can use it via PECL if they wish and configure it how they
want, and all config file syntax changes and such can be done inside of
PECL)- Make it 100% PECL (don't think this is possible as it needs too many
things inside of the core of PHP to be changed)- Keep it as a patch (lower adoption, current status quo)
When we talk about "core" changes - what these changes are? I.e. does it
need any changes besides the usual SAPI stuff and if so, which ones?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com