Hi!
We have today been asked by Debian and Ubuntu Maintainers to merge our
code up to PHP repository.
They have stated that they want to see the fpm sapi variant officially
supported.
It would be nice to hear what you guy's official decision would be
about something like this.
Here are some details about the FPM Project, and it's current status:
Andrei has done very clean, pristine code since forking the fcgi-sapi
and moving it forward in the 0.602.
I have been involved recently in this simply as a packager for the new
0.6 line of FPM Project.
We maintain ourselves as a seperate project on launchpad, and have not
submitting any code to you guys (PHP).
But since this request from debian/ubuntu, i guess we need for some
type of upstream sync or import process.
We are versioned in bzr and github.
Autoconf
This project relies upon its own versions of the autoconf toolset to
generate its ./configure script. To use autoconf, then run
./build-autotools which will install it locally in the directory. If
./build-autotools fails we have more information in
autoconf.markdown.
Build process
Compilation is pretty straightforward and hassle-free. The make
process can be described as:
- Compile the php sources into object files in the php build directory
- Compile the fpm sources into object files in the fpm build directory
- Link all the php object file with these fpm object file together
- Output: Static php5 binary, which is php base and using the fpm's
version of fcgi-SAPI as frontend
Fpm is mixed into php at the link-level. This de-couples the fpm
sources, making the process manager part somewhat less sensitive to
changes in the php project. PHP-FPM is derived from the fcgi-sapi. We
no longer patch directly onto php-maintained files. Instead there are
3 similar counterpart files from sapi/cgi and fpm's sapi are
periodically synced to them. Libevent library is included for the
process management.
Licence
Fpm has a very minimal licence. Fpm-sapi is a php license. The bundled
Libevent library is OpenBSD.
Please Contact Andrei Nigmatulin regarding any further licensing questions.
You should otherwise credit Andrei Nigmatulin as the author of /fpm sources.
Compatibility
Fpm 0.6.3+ is coming soon for the following versions of php:
php-5.2.10+ (ready)
php-5.3.any (definitely coming this week)
php-6.0 /trunk (may be this week also, if no hitch)
The script in our src tree 'generate-fpm-patch' is a possible way to
sync changes.
Or perhaps there's a better way to get from bzr into a subtree as svn.
The project's sub-tree is;
config/
libevent/
man/
src/
src/fpm/
src/sapi/
Would we be required to change the layout of our project's subtree?
And then which directory can it exist?
a) ext/fpm/
b) fpm/
c) sapi/fpm/ ?
Again, please any thoughts / discussion welcome.
Best regards,
dreamcat4
dreamcat4@gmail.com
This has been discussed before. See:
http://news.php.net/php.internals/44476
http://news.php.net/php.internals/44480
http://news.php.net/php.internals/44484
http://news.php.net/php.internals/44485
Basically it comes down to figuring out whether to extend the existing
FastCGI SAPI to support the process management in FPM, or add it as a
separate SAPI.
-Rasmus
dreamcat four wrote:
Hi!
We have today been asked by Debian and Ubuntu Maintainers to merge our
code up to PHP repository.
They have stated that they want to see the fpm sapi variant officially
supported.It would be nice to hear what you guy's official decision would be
about something like this.
Here are some details about the FPM Project, and it's current status:Andrei has done very clean, pristine code since forking the fcgi-sapi
and moving it forward in the 0.602.
I have been involved recently in this simply as a packager for the new
0.6 line of FPM Project.We maintain ourselves as a seperate project on launchpad, and have not
submitting any code to you guys (PHP).
But since this request from debian/ubuntu, i guess we need for some
type of upstream sync or import process.We are versioned in bzr and github.
Autoconf
This project relies upon its own versions of the autoconf toolset to
generate its./configurescript. To use autoconf, then run
./build-autotoolswhich will install it locally in the directory. If
./build-autotoolsfails we have more information in
autoconf.markdown.Build process
Compilation is pretty straightforward and hassle-free. The make
process can be described as:
- Compile the php sources into object files in the php build directory
- Compile the fpm sources into object files in the fpm build directory
- Link all the php object file with these fpm object file together
- Output: Static php5 binary, which is php base and using the fpm's
version of fcgi-SAPI as frontendFpm is mixed into php at the link-level. This de-couples the fpm
sources, making the process manager part somewhat less sensitive to
changes in the php project. PHP-FPM is derived from the fcgi-sapi. We
no longer patch directly onto php-maintained files. Instead there are
3 similar counterpart files from sapi/cgi and fpm's sapi are
periodically synced to them. Libevent library is included for the
process management.Licence
Fpm has a very minimal licence. Fpm-sapi is a php license. The bundled
Libevent library is OpenBSD.
Please Contact Andrei Nigmatulin regarding any further licensing questions.
You should otherwise credit Andrei Nigmatulin as the author of /fpm sources.Compatibility
Fpm 0.6.3+ is coming soon for the following versions of php:
php-5.2.10+ (ready)
php-5.3.any (definitely coming this week)
php-6.0 /trunk (may be this week also, if no hitch)The script in our src tree 'generate-fpm-patch' is a possible way to
sync changes.
Or perhaps there's a better way to get from bzr into a subtree as svn.The project's sub-tree is;
config/
libevent/
man/
src/
src/fpm/
src/sapi/Would we be required to change the layout of our project's subtree?
And then which directory can it exist?a) ext/fpm/
b) fpm/
c) sapi/fpm/ ?Again, please any thoughts / discussion welcome.
Best regards,
dreamcat4
dreamcat4@gmail.com
I'm 99% sure, this proposal this time around is for a seperate SAPI
only. So that's not the question being asked here.
The question is: Do you want fpm-sapi (or not)?
This has been discussed before. See:
http://news.php.net/php.internals/44476
http://news.php.net/php.internals/44480
http://news.php.net/php.internals/44484
http://news.php.net/php.internals/44485Basically it comes down to figuring out whether to extend the existing
FastCGI SAPI to support the process management in FPM, or add it as a
separate SAPI.-Rasmus
Hi!
The question is: Do you want fpm-sapi (or not)?
If it applies cleanly to PHP and doesn't require changes in the core,
then why not?
But for that I guess there should be some build modifications that make
common build (i.e., as for other modules - one runs configure/make and
gets the binary) - is it possible? If so, then I see no problem making
sapi/fpm.
Not sure about bundling libevent though - does it have to be bundled?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
The question is: Do you want fpm-sapi (or not)?
If it applies cleanly to PHP and doesn't require changes in the core, then
why not?
But for that I guess there should be some build modifications that make
common build (i.e., as for other modules - one runs configure/make and gets
the binary) - is it possible? If so, then I see no problem making sapi/fpm.
Its coming with it's own ./configure. I think you can hang one
configure script off from another because that's how fpm configures
its libevent library. This would be much preffered way. However you'd
then also have to be forwarding the fpm-specific configure flags
onward from the main php configure script. Im not sure how to do that
yet. But once the Makefile is created, then make-stage is like an
automatic recursion thing isn't it?
BTW all the debian maintainers asked for is the fpm sourcecode to be
supplied in the php-src folder. (rather than created from a patch
file). They said nothing about requiring to share the same build
command. I mention this because it didn't represent any kind of
technical issue for making a debian package. Indeed it seemed easier
not to.
Not sure about bundling libevent though - does it have to be bundled?
Don't know. Libevent is frozen in there and a couple of files were
modified with references back into the fpm headers.
The Libevent was updated recently anyway, so its a pretty recent version.
dreamcat4
dreamcat4@gmail.com
Hi!
Its coming with it's own ./configure. I think you can hang one
I'd suspect most of what it's configure is doing is done by the php one
too, and the rest can be converted to PHP's configure fragment. The
thing is that if you want to have it in PHP tree, it won't look too good
for it to have its own configure, no other SAPI does that and there's no
reason to.
As for bundling libevent, I have no idea if BSD code can be put in php
tree... It'd be much nicer if these chanegs were merged into libevent -
it seems to be pretty alive, 3 releases this year.
yet. But once the Makefile is created, then make-stage is like an
automatic recursion thing isn't it?
If you do it by PHP standards, it is, but otherwise I don't know - let
configure gurus on the list speak about it.
file). They said nothing about requiring to share the same build
command. I mention this because it didn't represent any kind of
technical issue for making a debian package. Indeed it seemed easier
not to.
Well, PHP has certain rules and customs of how SAPIs are built. Of
course, you can take PHP code and do whatever you like with it (if you
not call the result PHP without permission :) but if it's going to be
inside PHP tree then it should be organized by PHP rules. Otherwise PHP
tree would be an incomprehensible mess.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
As for bundling libevent, I have no idea if BSD code can be put in php
tree... It'd be much nicer if these chanegs were merged into libevent - it
seems to be pretty alive, 3 releases this year.
That's what I've been saying. If it's something that should be
patched/changed in libevent, attack it there and just make it a
dependency. No more packaging it together.
Not sure about bundling libevent though - does it have to be bundled?
Don't know. Libevent is frozen in there and a couple of files were
modified with references back into the fpm headers.
The Libevent was updated recently anyway, so its a pretty recent version.
just FYI this will also be problematic. as some of the other php devs
are probably well aware (hi pierre!), we have a pretty strict policy
against using embedded libraries, even more so for embedded libraries
that have been locally modified.
sean
hi,
Not sure about bundling libevent though - does it have to be bundled?
Don't know. Libevent is frozen in there and a couple of files were
modified with references back into the fpm headers.
The Libevent was updated recently anyway, so its a pretty recent version.just FYI this will also be problematic. as some of the other php devs
are probably well aware (hi pierre!), we have a pretty strict policy
against using embedded libraries, even more so for embedded libraries
that have been locally modified.
I would like to see strict policies too about respecting upstream
design decisions or implementations. But I won't hijack that thread to
kill a dead cow :)
Cheers,
Pierre
Not sure about bundling libevent though - does it have to be bundled?
Don't know. Libevent is frozen in there and a couple of files were
modified with references back into the fpm headers.
The Libevent was updated recently anyway, so its a pretty recent version.just FYI this will also be problematic. as some of the other php devs
are probably well aware (hi pierre!), we have a pretty strict policy
against using embedded libraries, even more so for embedded libraries
that have been locally modified.
Yeah, NO THANKS. We have enough of unmaintained code already. Since you
want this fpm thing into upstream PHP releases, why not make the changes
into libevent go upstream as well and then reconsider bundling, merging,
etc.
--Jani
Yeah, NO THANKS. We have enough of unmaintained code already. Since
you want this fpm thing into upstream PHP releases, why not make the
changes into libevent go upstream as well and then reconsider
bundling, merging, etc.
that seems a natural corollary, yes. that or remove the need for making
the local modifications in the first place. i'm not at all familiar
with the fpm project so wasn't aware of this until it was brought up, and
i don't know the specifics of how/why the library has been modified.
i should also point out that it's not exactly that I want this to be
included in php... all i know is that as a general rule when someone
comes along saying "hey can you apply this huge patch for a new feature",
i'm inclined to first point them at the upstream developers to try to
get it sorted out there.
this allows for a certain level of code review and the chance to get an
idea of what you think of the feature, as well as potentially benefitting
the entire php user base (if you take it) vs. the limited one of those
using debian-derived php packages (if we take it). and if you don't
like/want the patch, it would be good to know the reasons as it'd help
us decide whether or not we want it too.
sean
This has been discussed before. See:
http://news.php.net/php.internals/44476
http://news.php.net/php.internals/44480
http://news.php.net/php.internals/44484
http://news.php.net/php.internals/44485Basically it comes down to figuring out whether to extend the existing
FastCGI SAPI to support the process management in FPM, or add it as a
separate SAPI.
As separate SAPI, wouldn't it duplicate a LOT of code, basically for
nothing? I'd rather see the good parts of this merged into the
one-and-only sapi/cgi/ code instead of creating yet another SAPI nobody
maintains for real.
--Jani
-Rasmus
dreamcat four wrote:
Hi!
We have today been asked by Debian and Ubuntu Maintainers to merge our
code up to PHP repository.
They have stated that they want to see the fpm sapi variant officially
supported.It would be nice to hear what you guy's official decision would be
about something like this.
Here are some details about the FPM Project, and it's current status:Andrei has done very clean, pristine code since forking the fcgi-sapi
and moving it forward in the 0.602.
I have been involved recently in this simply as a packager for the new
0.6 line of FPM Project.We maintain ourselves as a seperate project on launchpad, and have not
submitting any code to you guys (PHP).
But since this request from debian/ubuntu, i guess we need for some
type of upstream sync or import process.We are versioned in bzr and github.
Autoconf
This project relies upon its own versions of the autoconf toolset to
generate its./configurescript. To use autoconf, then run
./build-autotoolswhich will install it locally in the directory. If
./build-autotoolsfails we have more information in
autoconf.markdown.Build process
Compilation is pretty straightforward and hassle-free. The make
process can be described as:
- Compile the php sources into object files in the php build directory
- Compile the fpm sources into object files in the fpm build directory
- Link all the php object file with these fpm object file together
- Output: Static php5 binary, which is php base and using the fpm's
version of fcgi-SAPI as frontendFpm is mixed into php at the link-level. This de-couples the fpm
sources, making the process manager part somewhat less sensitive to
changes in the php project. PHP-FPM is derived from the fcgi-sapi. We
no longer patch directly onto php-maintained files. Instead there are
3 similar counterpart files from sapi/cgi and fpm's sapi are
periodically synced to them. Libevent library is included for the
process management.Licence
Fpm has a very minimal licence. Fpm-sapi is a php license. The bundled
Libevent library is OpenBSD.
Please Contact Andrei Nigmatulin regarding any further licensing questions.
You should otherwise credit Andrei Nigmatulin as the author of /fpm sources.Compatibility
Fpm 0.6.3+ is coming soon for the following versions of php:
php-5.2.10+ (ready)
php-5.3.any (definitely coming this week)
php-6.0 /trunk (may be this week also, if no hitch)The script in our src tree 'generate-fpm-patch' is a possible way to
sync changes.
Or perhaps there's a better way to get from bzr into a subtree as svn.The project's sub-tree is;
config/
libevent/
man/
src/
src/fpm/
src/sapi/Would we be required to change the layout of our project's subtree?
And then which directory can it exist?a) ext/fpm/
b) fpm/
c) sapi/fpm/ ?Again, please any thoughts / discussion welcome.
Best regards,
dreamcat4
dreamcat4@gmail.com
Hi!
As separate SAPI, wouldn't it duplicate a LOT of code, basically for
nothing? I'd rather see the good parts of this merged into the
one-and-only sapi/cgi/ code instead of creating yet another SAPI nobody
maintains for real.
If the code will be really the same exactly, then maybe it can be just
reused (e.g. functions, etc.)? If not, then somewhat similar code I
don't think is a problem if it's maintained, and if it's not then better
have unmaintaned separate SAPI then unmaintained pieces of code inside
of one of most used SAPIs :)
In general, I'd consider changing sapi/cgi adding new potentially
unstable hode rather high-risk, unless it can be very well isolated.
sapi/cgi runs quite a lot of code...
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
As separate SAPI, wouldn't it duplicate a LOT of code, basically for
nothing? I'd rather see the good parts of this merged into the
one-and-only sapi/cgi/ code instead of creating yet another SAPI
nobody maintains for real.If the code will be really the same exactly, then maybe it can be just
reused (e.g. functions, etc.)? If not, then somewhat similar code I
don't think is a problem if it's maintained, and if it's not then better
have unmaintaned separate SAPI then unmaintained pieces of code inside
of one of most used SAPIs :)
In general, I'd consider changing sapi/cgi adding new potentially
unstable hode rather high-risk, unless it can be very well isolated.
sapi/cgi runs quite a lot of code...
Very good point. And I did consider only merging the good parts of
this thing. I haven't had time to check the code yet at all (quite busy
at work right now) but there are some stuff it does we haven't generally
considered the "job of PHP" before. The list of them is here:
http://php-fpm.org/What_is_PHP-FPM
--Jani
Very good point. And I did consider only merging the good parts of this
thing. I haven't had time to check the code yet at all (quite busy at work
right now) but there are some stuff it does we haven't generally considered
the "job of PHP" before. The list of them is here:
Current:
Proper termination of errant processes
FastCGI pool configuration, management, proper child recycling
Per-pool php.ini overrides
Future:
Adaptive process spawning (has been in the plans for a while but
Andrei never got a chance to get around to finishing it)
Hopefully some metrics/reporting
Probably changing the configuration file syntax
Per-pool specific php.ini file (basically just php-cgi -c, very simple
addition to add)
(look at the Wishlist page on the wiki...)
Lots of room for improvement. I think it will help with resource
management as well. Right now you have to arbitrarily assign how many
children you want without any real way to measure if it's too many or
too little.
I had suggested this idea at one point - that is adding in only what
is needed from PHP-FPM into PHP core and allowing the management of
those hooks from an external tool developed and maintained separately
(or through API calls) - then a variety of tools could manage the
portions of the FastCGI SAPI that PHP-FPM does to terminate processes,
spawn new children, and do whatever else was patched into PHP, and
keep the management portion which is in charge of launching children,
monitoring them, all that in its own standalone package. I see it as
both allowing for more agile development on the management portion as
it is lacking in a lot of features that we'd like to see (and not have
to wait on PHP core's release cycle to get them in) and also can be
packaged separately in distributions, much like spawn-fcgi is right
now.
Essentially it could be thought of as moving in the direction of
spawn-fcgi (being standalone), just with more robust PHP
functionality.
Hi!
Very good point. And I did consider only merging the good parts of
this thing. I haven't had time to check the code yet at all (quite busy
at work right now) but there are some stuff it does we haven't generally
considered the "job of PHP" before. The list of them is here:
Exactly. That's why I don't have a problem of it being a separate SAPI -
we have about 20, what harm could one more do? :) It's much safer this
way. And if we discover merging into sapi/cgi really makes sense - at
least we'd have code that already works with php, plays by php rules,
etc. so it'd be much easier and safer.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Exactly. That's why I don't have a problem of it being a separate SAPI - we
have about 20, what harm could one more do? :) It's much safer this way. And
if we discover merging into sapi/cgi really makes sense - at least we'd have
code that already works with php, plays by php rules, etc. so it'd be much
easier and safer.
From outside this also seems like the correct route to take. A much
better place from which to re-work any common codes.
In regards to libevent library, it's probably enough discussions for
now as we all seem in agreement. We shall see about getting libevent
moved out from the fpm-0.6.4 sources and changed over to a libtool
dependancy. I guess it can't be particularly very much work to solve.
dreamcat4
dreamcat4@gmail.com
Exactly. That's why I don't have a problem of it being a separate SAPI - we
have about 20, what harm could one more do? :) It's much safer this way. And
if we discover merging into sapi/cgi really makes sense - at least we'd have
code that already works with php, plays by php rules, etc. so it'd be much
easier and safer.From outside this also seems like the correct route to take. A much
better place from which to re-work any common codes.In regards to libevent library, it's probably enough discussions for
now as we all seem in agreement. We shall see about getting libevent
moved out from the fpm-0.6.4 sources and changed over to a libtool
dependancy. I guess it can't be particularly very much work to solve.
I would actually suggest to make a branch in the PHP SVN so that you can
make the modifications in there and make things work. From there on we
could then merge it into PHP proper. The PHP configure and build things
make quite a few assumptions and I think you'll run into some issues at
some point. It'll also allow us to peek and offer some assistence while
things are being worked on.
regards,
Derick
--
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
twitter: @derickr
I would actually suggest to make a branch in the PHP SVN so that you can
make the modifications in there and make things work. From there on we
Thank you. Don't have svn-commit access so kindda need to get that.
could then merge it into PHP proper. The PHP configure and build things
make quite a few assumptions and I think you'll run into some issues at
some point. It'll also allow us to peek and offer some assistence while
things are being worked on.
Won't be altering php configure / acinclude.m4 until it's sitting in a
svn branch.
Whats best to start on initially: 5.2.X, 5.3.X or trunk/6.0 ?
I'm okay with 5.3 but open to suggestions.
Best regards,
dreamcat4
dreamcat4@gmail.com
I would actually suggest to make a branch in the PHP SVN so that you
can make the modifications in there and make things work. From there
on weThank you. Don't have svn-commit access so kindda need to get that.
Yeah, that can be arranged of course: http://www.php.net/svn-php.php I
can create a branch for you once you have an account.
could then merge it into PHP proper. The PHP configure and build
things make quite a few assumptions and I think you'll run into some
issues at some point. It'll also allow us to peek and offer some
assistence while things are being worked on.Won't be altering php configure / acinclude.m4 until it's sitting in a
svn branch.Whats best to start on initially: 5.2.X, 5.3.X or trunk/6.0 ?
I'm okay with 5.3 but open to suggestions.
New features only go into trunk usually... but if this is totally stand
alone I don't mind having it in 5.3 either (that's my own personal
opinion though).
regards,
Derick
--
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
twitter: @derickr
Hi!
New features only go into trunk usually... but if this is totally stand
alone I don't mind having it in 5.3 either (that's my own personal
opinion though).
I think if it goes to branch and is isolated as SAPI should be there
shouldn't be a problem to merge it to 5.3 when it's ready.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com