I'm building a script that installs PHP 5.3.10 from source. One of the
steps is to install apc and mongo support via pecl. I'm building the
CGI/FastCGI version. This is on a box that formerly had mod_php
installed.
If I do 'make install' of PHP (which installs a new pecl binary) and
follow it up immediately with 'pecl install apc', the apc extension
winds up here:
/usr/local/lib/php/extensions/no-debug-zts-20090626
That's not what command line php and php-cgi are looking for, so they
produce warnings and don't load the extensions.
However If I do the pecl install later - possibly after restarting
Apache with fastcgi enabled - it installs to the new, correct place:
no-debug-non-zts-20090626
The warnings go away, and everything is great.
This raises two questions about which no documentation seems to exist
after quite a bit of searching and which raise questions about whether
PHP is doing sensible things, so I took the liberty of bringing them
to folks who actually understand PHP's internals.
-
You only get one pecl binary although you may have many SAPIs
installed. mod_php defaults to thread-safe (and there seems to be no
way to turn that off on Linux), while php-cgi does not. So how does
pecl decide which way to build extensions? I tried setting
extensions_dir via config-set, but that setting was ignored (unless
perhaps it falls back if the folder doesn't exist yet?). How can I
ensure that, having just installed PHP and pecl, my next pecl install
will build extensions for the right flavor of PHP? -
Why does php turn on thread-safety for mod_php at all on Linux,
given that it apparently still doesn't work very well with various
extensions in a genuinely multithreaded situation, slows things down,
takes more memory, and leads to problems like this one?
Everyone I've found runs PHP under the Apache prefork MPM, which does
not attempt to run PHP in multiple threads of one process. I have
never seen anyone successfully use the worker MPM with PHP, except by
moving PHP out to a fastcgi process pool, which is, again,
single-process PHP.
Even Microsoft's PHP accelerator uses the fastcgi-based,
one-process-per-PHP-request approach. Since Windows is so
thread-oriented that seems significant.
I have attached my script.
Thanks for any insight!
Hi internals!
I have written an RFC that proposes to deprecate and remove the /e modifier:
https://wiki.php.net/rfc/remove_preg_replace_eval_modifier
Comments welcome!
--
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
As far as Windows is concerned, it is worth noting that the Apache mod_php
(i.e. ZTS) build is supported. Also, though my information is a bit
outdated, last I heard work was being done to support thread-safe PHP as an
ISAPI module on IIS, though I don't know what the status of that is.
--Kris
I'm building a script that installs PHP 5.3.10 from source. One of the
steps is to install apc and mongo support via pecl. I'm building the
CGI/FastCGI version. This is on a box that formerly had mod_php
installed.If I do 'make install' of PHP (which installs a new pecl binary) and
follow it up immediately with 'pecl install apc', the apc extension
winds up here:/usr/local/lib/php/extensions/no-debug-zts-20090626
That's not what command line php and php-cgi are looking for, so they
produce warnings and don't load the extensions.However If I do the pecl install later - possibly after restarting
Apache with fastcgi enabled - it installs to the new, correct place:no-debug-non-zts-20090626
The warnings go away, and everything is great.
This raises two questions about which no documentation seems to exist
after quite a bit of searching and which raise questions about whether
PHP is doing sensible things, so I took the liberty of bringing them
to folks who actually understand PHP's internals.
You only get one pecl binary although you may have many SAPIs
installed. mod_php defaults to thread-safe (and there seems to be no
way to turn that off on Linux), while php-cgi does not. So how does
pecl decide which way to build extensions? I tried setting
extensions_dir via config-set, but that setting was ignored (unless
perhaps it falls back if the folder doesn't exist yet?). How can I
ensure that, having just installed PHP and pecl, my next pecl install
will build extensions for the right flavor of PHP?Why does php turn on thread-safety for mod_php at all on Linux,
given that it apparently still doesn't work very well with various
extensions in a genuinely multithreaded situation, slows things down,
takes more memory, and leads to problems like this one?Everyone I've found runs PHP under the Apache prefork MPM, which does
not attempt to run PHP in multiple threads of one process. I have
never seen anyone successfully use the worker MPM with PHP, except by
moving PHP out to a fastcgi process pool, which is, again,
single-process PHP.Even Microsoft's PHP accelerator uses the fastcgi-based,
one-process-per-PHP-request approach. Since Windows is so
thread-oriented that seems significant.I have attached my script.
Thanks for any insight!
On Sun, Feb 5, 2012 at 9:59 AM, Nikita Popov nikita.ppv@googlemail.com
wrote:Hi internals!
I have written an RFC that proposes to deprecate and remove the /e
modifier:https://wiki.php.net/rfc/remove_preg_replace_eval_modifier
Comments welcome!
--
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
Good point. Last I tried that it worked poorly - I couldn't find a
bytecode cache that worked with it, performance was poor - and I
switched to the Microsoft accelerator and IIS. But things may have
changed.
Doesn't really explain it on Linux...
But what I really want to know is just how to get predictable behavior
in my script - after installing a new PHP and pecl I should be able to
do pecl installs and have them show up in the right extensions folder
for the PHP I just built, but no such luck.
(Yes, /usr/local/bin/pecl is the one I just built.)
As far as Windows is concerned, it is worth noting that the Apache mod_php
(i.e. ZTS) build is supported. Also, though my information is a bit
outdated, last I heard work was being done to support thread-safe PHP as an
ISAPI module on IIS, though I don't know what the status of that is.--Kris
I'm building a script that installs PHP 5.3.10 from source. One of the
steps is to install apc and mongo support via pecl. I'm building the
CGI/FastCGI version. This is on a box that formerly had mod_php
installed.If I do 'make install' of PHP (which installs a new pecl binary) and
follow it up immediately with 'pecl install apc', the apc extension
winds up here:/usr/local/lib/php/extensions/no-debug-zts-20090626
That's not what command line php and php-cgi are looking for, so they
produce warnings and don't load the extensions.However If I do the pecl install later - possibly after restarting
Apache with fastcgi enabled - it installs to the new, correct place:no-debug-non-zts-20090626
The warnings go away, and everything is great.
This raises two questions about which no documentation seems to exist
after quite a bit of searching and which raise questions about whether
PHP is doing sensible things, so I took the liberty of bringing them
to folks who actually understand PHP's internals.
You only get one pecl binary although you may have many SAPIs
installed. mod_php defaults to thread-safe (and there seems to be no
way to turn that off on Linux), while php-cgi does not. So how does
pecl decide which way to build extensions? I tried setting
extensions_dir via config-set, but that setting was ignored (unless
perhaps it falls back if the folder doesn't exist yet?). How can I
ensure that, having just installed PHP and pecl, my next pecl install
will build extensions for the right flavor of PHP?Why does php turn on thread-safety for mod_php at all on Linux,
given that it apparently still doesn't work very well with various
extensions in a genuinely multithreaded situation, slows things down,
takes more memory, and leads to problems like this one?Everyone I've found runs PHP under the Apache prefork MPM, which does
not attempt to run PHP in multiple threads of one process. I have
never seen anyone successfully use the worker MPM with PHP, except by
moving PHP out to a fastcgi process pool, which is, again,
single-process PHP.Even Microsoft's PHP accelerator uses the fastcgi-based,
one-process-per-PHP-request approach. Since Windows is so
thread-oriented that seems significant.I have attached my script.
Thanks for any insight!
On Sun, Feb 5, 2012 at 9:59 AM, Nikita Popov nikita.ppv@googlemail.com
wrote:Hi internals!
I have written an RFC that proposes to deprecate and remove the /e
modifier:https://wiki.php.net/rfc/remove_preg_replace_eval_modifier
Comments welcome!
--
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com--
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
hi,
Good point. Last I tried that it worked poorly - I couldn't find a
bytecode cache that worked with it, performance was poor - and I
switched to the Microsoft accelerator and IIS. But things may have
changed.
APC with rwlock is faster than before under Apache:
http://www.php.net/~pierre/vcqa/apcigninary_perf.png
http://www.php.net/~pierre/vcqa/apc-rwlock-win.pdf
And that was possible only by doing changes in APC only.
Microsoft has no policy or whatever else when it comes to PHP but they
support FastCGI because it was easier for the IIS team to develop
FastCGI support for IIS than trying to get support via ISAPI for all
other languages. But it is imo a bad design solution (long term),
while working very so far.
PHP on windows supports both NTS and TS (Apache) and will certainly
support again TS under IIS again in PHP next.
Doesn't really explain it on Linux...
But what I really want to know is just how to get predictable behavior
in my script - after installing a new PHP and pecl I should be able to
do pecl installs and have them show up in the right extensions folder
for the PHP I just built, but no such luck.
that's why php-config exists, use it to get which version of PHP is
installed or has to be used (nts, ts, php version, api version, etc.).
That's all parameter you need to know. php-config should give you the
path as well afair.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
that's why php-config exists, use it to get which version of PHP is
installed or has to be used (nts, ts, php version, api version, etc.).
That's all parameter you need to know. php-config should give you the
path as well afair.
Then shouldn't a 'make install' of PHP have changed php-config on the
spot? Why wouldn't the pecl install I do immediately after that be
aware of the changes? The delay is what's puzzling. What good does it
do me to look at php-config output if pecl doesn't seem to?
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
Once a package has been fetched, pecl install does nothing else than:
phpize, make, make install
and phpize does use php-config.
that's why php-config exists, use it to get which version of PHP is
installed or has to be used (nts, ts, php version, api version, etc.).
That's all parameter you need to know. php-config should give you the
path as well afair.Then shouldn't a 'make install' of PHP have changed php-config on the
spot? Why wouldn't the pecl install I do immediately after that be
aware of the changes? The delay is what's puzzling. What good does it
do me to look at php-config output if pecl doesn't seem to?--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
- Why does php turn on thread-safety for mod_php at all on Linux,
given that it apparently still doesn't work very well with various
extensions in a genuinely multithreaded situation, slows things down,
takes more memory, and leads to problems like this one?
I can't recall who, but I have heard people who claim to run
multi-threaded on Linux, but with a heck of a lot of stress testing,
and a rigid control on minimal extensions added...
So apparently somebody uses it.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
PHP through mod_php on Linux should compile without ZTS.
configure script searches for apxs binary and tries to invoque "apxs -q
MPM" to figure out what MPM has been compiled in Apache for the TS flag to
be defined or not (thus, activating PHP ZTS, or not).
Mainly on Linux, Apache should have been installed with prefork MPM ans
"apxs -q" should return that, then configure should not define
PHP_BUILD_THREAD_SAFE.
Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer
about the MPM configuration anymore, leading to a ZTS build by default.
This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172.
I dont know anything about windows, sorry
Julien.Pauli
- Why does php turn on thread-safety for mod_php at all on Linux,
given that it apparently still doesn't work very well with various
extensions in a genuinely multithreaded situation, slows things down,
takes more memory, and leads to problems like this one?I can't recall who, but I have heard people who claim to run
multi-threaded on Linux, but with a heck of a lot of stress testing,
and a rigid control on minimal extensions added...So apparently somebody uses it.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
PHP through mod_php on Linux should compile without ZTS.
configure script searches for apxs binary and tries to invoque "apxs -q
MPM" to figure out what MPM has been compiled in Apache for the TS flag to
be defined or not (thus, activating PHP ZTS, or not).
Right...
Mainly on Linux, Apache should have been installed with prefork MPM ans
"apxs -q" should return that, then configure should not define
PHP_BUILD_THREAD_SAFE.
No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux
distros have moved away from it...
Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer
about the MPM configuration anymore, leading to a ZTS build by default.
This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172.
Wrong fix. Out of the box you don't know which mpm may be loaded, because
the mpm is now loadable (although a full daemon stop/start is necessary).
The only mod_php loadable under any circumstance is TS enabled.
If you want php/linux single-child, fastcgi is the only rational approach.
I dont know anything about windows, sorry
Always threaded.
Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer
about the MPM configuration anymore, leading to a ZTS build by default.
This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172.Wrong fix. Out of the box you don't know which mpm may be loaded, because
the mpm is now loadable (although a full daemon stop/start is necessary).
Can you expand & explain this, with an eye to resolving 61172?
Are you saying Apache 2.4 'httpd -M' might not return the mpm?
The only mod_php loadable under any circumstance is TS enabled.
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Recently we had a bug with the new Apache 2.4 API where apxs
doesn't answer
about the MPM configuration anymore, leading to a ZTS build by
default.
This bug has now been fixed, was
https://bugs.php.net/bug.php?id=61172.Wrong fix. Out of the box you don't know which mpm may be loaded,
because
the mpm is now loadable (although a full daemon stop/start is
necessary).Can you expand & explain this, with an eye to resolving 61172?
Are you saying Apache 2.4 'httpd -M' might not return the mpm?
If I'm reading this correctly:
apxs runs at PHP compile time and "reads" mpm from httpd.conf
Apache is started, probably with that mpm, and then a different mpm is
loaded and apache is re-started, maybe even with graceful, for real
fun.
mod_php has no knowledge of the "new" mpm, because the mpm choice was
compiled in at apxs time.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer
about the MPM configuration anymore, leading to a ZTS build by default.
This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172.Wrong fix. Out of the box you don't know which mpm may be loaded, because
the mpm is now loadable (although a full daemon stop/start is necessary).Can you expand & explain this, with an eye to resolving 61172?
Are you saying Apache 2.4 'httpd -M' might not return the mpm?
The mpm is now a loadable module, not compiled in. The recommended default mpm
is now event, the recommended .rpm proposes shipping event/worker/prefork, all
as modules. The user is free to switch mpm's at any point by simply editing
their httpd.conf file, so what was a non-threaded server becomes a threaded one.
httpd -l will not return what you want, httpd -M will, but is not the right
solution...
bin/httpd -l
Compiled in modules:
core.c
mod_so.c
http_core.c
bin/httpd -M
Loaded Modules:
core_module (static)
so_module (static)
http_module (static)
...
version_module (shared)
mpm_event_module (shared)
unixd_module (shared)
...
The httpd -V command was always the correct way to test for threaded'ness,
which would allow supporting an mpm which was not known to you. Again, it
will only reflect the currently loaded module (and fail if no MPM is loaded);
bin/httpd -V
Server version: Apache/2.4.1 (Unix)
Server built: Feb 28 2012 10:37:32
Server's Module Magic Number: 20120211:0
Server loaded: APR 1.4.5, APR-UTIL 1.3.12
Compiled using: APR 1.4.5, APR-UTIL 1.3.12
Architecture: 64-bit
Server MPM: event
threaded: yes (fixed thread count)
forked: yes (variable process count)
...
Editing httpd.conf... s/event/prefork/ results in
...
Server MPM: prefork
threaded: no
forked: yes (variable process count)
In 2.2 the default MPM became worker. In 2.4 the default MPM is now event,
so prefork hasn't been the default in some 7 years. The only sensible build
for mod_php is ZTS, which will load and operate whichever mpm is loaded by
the user. The only sensible single thread environment is cgi (enhanced,
of course, with fastcgi!)
Hi!
so prefork hasn't been the default in some 7 years. The only sensible build
for mod_php is ZTS, which will load and operate whichever mpm is loaded by
the user. The only sensible single thread environment is cgi (enhanced,
of course, with fastcgi!)
Please note that TS build is slower and has higher memory requirements
(due to TS locks and TS data structures) so having it as only build may
not be optimal.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
so prefork hasn't been the default in some 7 years. The only sensible build
for mod_php is ZTS, which will load and operate whichever mpm is loaded by
the user. The only sensible single thread environment is cgi (enhanced,
of course, with fastcgi!)Please note that TS build is slower and has higher memory requirements (due to TS locks
and TS data structures) so having it as only build may not be optimal.
Of course, which is why a cgi build is /also/ useful. But I just don't see
performance complaints, they are almost always reliability or configuration
issues. If you are running that close to the edge that the 15% performance
penalty kills your box, you were well past time to scale to more boxes or
to review the PHP code itself for performance issues.
Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer
about the MPM configuration anymore, leading to a ZTS build by default.
This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172.Wrong fix. Out of the box you don't know which mpm may be loaded, because
the mpm is now loadable (although a full daemon stop/start is necessary).Can you expand& explain this, with an eye to resolving 61172?
Are you saying Apache 2.4 'httpd -M' might not return the mpm?The mpm is now a loadable module, not compiled in. The recommended default mpm
is now event, the recommended .rpm proposes shipping event/worker/prefork, all
as modules. The user is free to switch mpm's at any point by simply editing
their httpd.conf file, so what was a non-threaded server becomes a threaded one.httpd -l will not return what you want, httpd -M will, but is not the right
solution...bin/httpd -l
Compiled in modules:
core.c
mod_so.c
http_core.cbin/httpd -M
Loaded Modules:
core_module (static)
so_module (static)
http_module (static)
...
version_module (shared)
mpm_event_module (shared)
unixd_module (shared)
...The httpd -V command was always the correct way to test for threaded'ness,
which would allow supporting an mpm which was not known to you. Again, it
will only reflect the currently loaded module (and fail if no MPM is loaded);bin/httpd -V
Server version: Apache/2.4.1 (Unix)
Server built: Feb 28 2012 10:37:32
Server's Module Magic Number: 20120211:0
Server loaded: APR 1.4.5, APR-UTIL 1.3.12
Compiled using: APR 1.4.5, APR-UTIL 1.3.12
Architecture: 64-bit
Server MPM: event
threaded: yes (fixed thread count)
forked: yes (variable process count)
...Editing httpd.conf... s/event/prefork/ results in
...
Server MPM: prefork
threaded: no
forked: yes (variable process count)In 2.2 the default MPM became worker. In 2.4 the default MPM is now event,
so prefork hasn't been the default in some 7 years. The only sensible build
for mod_php is ZTS, which will load and operate whichever mpm is loaded by
the user. The only sensible single thread environment is cgi (enhanced,
of course, with fastcgi!)
Thanks for clarifying that there is nothing unexpected (to me)
happening and for suggesting using -V.
It seems that the PHP installer could do one of two things:
-
Build PHP for the currently installed Apache MPM, using "httpd -V"
to identify whether to enable PHP's ZTS mode or not. PHP
documentation and/or 'configure' messages should state the MPM
shouldn't later be changed to threaded if it was originally
prefork. A proviso about ZTS overhead and limitations could be
noted. -
Build PHP with ZTS enabled by default. Allow it to be explicitly
disabled during 'configure'
There are some variations of the above, depending on the target
audience(s) and scope of perceived problem.
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Build PHP with ZTS enabled by default. Allow it to be explicitly
disabled during 'configure'
Why punish everyone by default because of Apache? Does not make sense to
me.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
I'm not sure I'd take it quite that far. I've done benchmarking of NTS and
ZTS builds and the difference really isn't anything I would consider worth
worrying about in most cases. It's fairly minor.
--Kris
On Tue, Feb 28, 2012 at 1:41 PM, Sebastian Bergmann sebastian@php.netwrote:
Build PHP with ZTS enabled by default. Allow it to be explicitly
disabled during 'configure'Why punish everyone by default because of Apache? Does not make sense to
me.--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Am 28.02.2012 22:41, schrieb Sebastian Bergmann:
Build PHP with ZTS enabled by default. Allow it to be explicitly
disabled during 'configure'Why punish everyone by default because of Apache? Does not make sense to
me.
even for apache it is a bad default
i bet the are more mod_php setups taht fast-cgi/cgi
Build PHP with ZTS enabled by default. Allow it to be explicitly
disabled during 'configure'Why punish everyone by default because of Apache? Does not make sense to
me.
What is so difficult to grok about
-
setting up php-cgi to use fastcgi as the httpd default.
-
having parallel non-zts and zts installs of php (notably with only
non-zts cli and cgi sapi's) with two different lib paths. Multiply
by two again if you have parallel i686 and x86_64 installs.
All of these are packager's questions anyways, as so few users do this
for themself, most hosters aren't rebuilding php either.
PHP would be a much nicer, friendly and more civilized development list
if it borrowed only one phrase from the Perl community; TMTOWTDI.
Build PHP with ZTS enabled by default. Allow it to be explicitly
disabled during 'configure'Why punish everyone by default because of Apache? Does not make sense to
me.What is so difficult to grok about
setting up php-cgi to use fastcgi as the httpd default.
having parallel non-zts and zts installs of php (notably with only
non-zts cli and cgi sapi's) with two different lib paths. Multiply
by two again if you have parallel i686 and x86_64 installs.All of these are packager's questions anyways, as so few users do this
for themself, most hosters aren't rebuilding php either.PHP would be a much nicer, friendly and more civilized development list
if it borrowed only one phrase from the Perl community; TMTOWTDI.
These are useful suggestions for a future "bigger picture" direction
about sensible defaults, usability (or lack of), php-fpm, etc. This
is a problem looking for an owner.
In the narrow confines of https://bugs.php.net/bug.php?id=61172 the
packager has deliberately chosen to install mod_php. Like Sebastian,
I prefer that PHP configures itself for the currently installed Apache
MPM.
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
hi Bill,
On Tue, Feb 28, 2012 at 11:29 PM, William A. Rowe Jr.
wrowe@rowe-clan.net wrote:
Build PHP with ZTS enabled by default. Allow it to be explicitly
disabled during 'configure'Why punish everyone by default because of Apache? Does not make sense to
me.What is so difficult to grok about
Nothing, but it is easier to get a point when the rhetorical comments
are removed :)
1. setting up php-cgi to use fastcgi as the httpd default.
2. having parallel non-zts and zts installs of php (notably with only
non-zts cli and cgi sapi's) with two different lib paths. Multiply
by two again if you have parallel i686 and x86_64 installs.All of these are packager's questions anyways, as so few users do this
for themself, most hosters aren't rebuilding php either.
Right, and that's a rather big change, package wised. While the
lbraries (systems) are the same, at lest for 99.99% of them. There are
a few which can be built in TS or not TS mode but I don't think it is
worth it.
PHP would be a much nicer, friendly and more civilized development list
if it borrowed only one phrase from the Perl community; TMTOWTDI.
Civilized sounds very wrong in this context, or in general these days.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi Bill,
On Tue, Feb 28, 2012 at 11:29 PM, William A. Rowe Jr.
wrowe@rowe-clan.net wrote:Build PHP with ZTS enabled by default. Allow it to be explicitly
disabled during 'configure'Why punish everyone by default because of Apache? Does not make sense
to
me.What is so difficult to grok about
Nothing, but it is easier to get a point when the rhetorical comments
are removed :)
setting up php-cgi to use fastcgi as the httpd default.
having parallel non-zts and zts installs of php (notably with only
non-zts cli and cgi sapi's) with two different lib paths. Multiply
by two again if you have parallel i686 and x86_64 installs.All of these are packager's questions anyways, as so few users do this
for themself, most hosters aren't rebuilding php either.Right, and that's a rather big change, package wised. While the
lbraries (systems) are the same, at lest for 99.99% of them. There are
a few which can be built in TS or not TS mode but I don't think it is
worth it.PHP would be a much nicer, friendly and more civilized development list
if it borrowed only one phrase from the Perl community; TMTOWTDI.Civilized sounds very wrong in this context, or in general these days.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Right, I suggest we leave #61172 as is, as it solves the problem.
PHP should be built with whatever MPM has been detected at configure time
(httpd -V) , and that's all.
The work of switching MPM later should be left to package maintainers, and
scripts like Debian's "a2enmod" which can handle that themselves.
Just my thoughts :)
Julien.P
hi Bill,
On Tue, Feb 28, 2012 at 11:29 PM, William A. Rowe Jr.
wrowe@rowe-clan.net wrote:Build PHP with ZTS enabled by default. Allow it to be explicitly
disabled during 'configure'Why punish everyone by default because of Apache? Does not make sense
to
me.What is so difficult to grok about
Nothing, but it is easier to get a point when the rhetorical comments
are removed :)
setting up php-cgi to use fastcgi as the httpd default.
having parallel non-zts and zts installs of php (notably with only
non-zts cli and cgi sapi's) with two different lib paths. Multiply
by two again if you have parallel i686 and x86_64 installs.All of these are packager's questions anyways, as so few users do this
for themself, most hosters aren't rebuilding php either.Right, and that's a rather big change, package wised. While the
lbraries (systems) are the same, at lest for 99.99% of them. There are
a few which can be built in TS or not TS mode but I don't think it is
worth it.PHP would be a much nicer, friendly and more civilized development list
if it borrowed only one phrase from the Perl community; TMTOWTDI.Civilized sounds very wrong in this context, or in general these days.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Right, I suggest we leave #61172 as is, as it solves the problem.
PHP should be built with whatever MPM has been detected at configure time
(httpd -V) , and that's all.The work of switching MPM later should be left to package maintainers, and
scripts like Debian's "a2enmod" which can handle that themselves.
You could in fact add a safety net by querying the threadedness of the
MPM during mod_php startup. There's a standard MPM query API in Apache,
which tells you whether a threaded MPM is in use. If the mod_php build
would be without thread support and the module detects a threaded MPM
during startup, it could prevent startup of Apache and output an error
message.
Regards,
Rainer
On Mon, Feb 27, 2012 at 10:12 PM, William A. Rowe Jr.
wrowe@rowe-clan.netwrote:
PHP through mod_php on Linux should compile without ZTS.
configure script searches for apxs binary and tries to invoque "apxs -q
MPM" to figure out what MPM has been compiled in Apache for the TS flag
to
be defined or not (thus, activating PHP ZTS, or not).Right...
Mainly on Linux, Apache should have been installed with prefork MPM ans
"apxs -q" should return that, then configure should not define
PHP_BUILD_THREAD_SAFE.No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux
distros have moved away from it...Sorry but 2.2 defaults to prefork.
The new 2.4 platform has introduced loadable MPM, like any other module ,
thus we cant detect through
apxs which MPM is used anymore. For this, we would need to play with httpd
-M
Recently we had a bug with the new Apache 2.4 API where apxs doesn't
answer
about the MPM configuration anymore, leading to a ZTS build by default.
This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172.Wrong fix. Out of the box you don't know which mpm may be loaded, because
the mpm is now loadable (although a full daemon stop/start is necessary).
The only mod_php loadable under any circumstance is TS enabled.
Yes, but ZTS has a performance/memory penalty due to globals locks.
I would much prefer having a nonZTS PHP together with a non threaded MPM
Julien.P
If you want php/linux single-child, fastcgi is the only rational approach.
I dont know anything about windows, sorry
Always threaded.
PHP needs a lot more memory than, say, serving static files. If you
used PHP with the worker threaded MPM, and it worked (I haven't heard
many stories of people doing this under Linux), wouldn't you just have
to dial back the number of threads to pretty much the number of
processes you would have allowed under the prefork MPM? The overhead
of a process is pretty tiny next to the overhead of a PHP framework.
Aren't you therefore just paying a performance and stability price
(threadsafe is slower than non-threadsafe, your extensions may or may
not play nice...) for not a lot of benefit under Linux when PHP runs
under the worker threaded MPM?
The best configuration I'm aware of is to run Apache with the worker
threaded MPM, and run PHP in a fastcgi pool, so that you can have
hundreds of threads serving static and cached content in a hurry, and
a smaller pool of more expensive PHP processes. I'm interested to hear
if anyone feels there is a superior model for single-server PHP
hosting under Linux.
(I realize that static files could be pushed out to CDNs and the like
but our clients much prefer to have a single straightforward hosting
bill to pay, thus the single-server thing for most cases.)
On Mon, Feb 27, 2012 at 10:12 PM, William A. Rowe Jr.
wrowe@rowe-clan.netwrote:PHP through mod_php on Linux should compile without ZTS.
configure script searches for apxs binary and tries to invoque "apxs -q
MPM" to figure out what MPM has been compiled in Apache for the TS flag
to
be defined or not (thus, activating PHP ZTS, or not).Right...
Mainly on Linux, Apache should have been installed with prefork MPM ans
"apxs -q" should return that, then configure should not define
PHP_BUILD_THREAD_SAFE.No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux
distros have moved away from it...Sorry but 2.2 defaults to prefork.
The new 2.4 platform has introduced loadable MPM, like any other module ,
thus we cant detect through
apxs which MPM is used anymore. For this, we would need to play with httpd
-MRecently we had a bug with the new Apache 2.4 API where apxs doesn't
answer
about the MPM configuration anymore, leading to a ZTS build by default.
This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172.Wrong fix. Out of the box you don't know which mpm may be loaded, because
the mpm is now loadable (although a full daemon stop/start is necessary).
The only mod_php loadable under any circumstance is TS enabled.Yes, but ZTS has a performance/memory penalty due to globals locks.
I would much prefer having a nonZTS PHP together with a non threaded MPMJulien.P
If you want php/linux single-child, fastcgi is the only rational approach.
I dont know anything about windows, sorry
Always threaded.
--
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
On Mon, Feb 27, 2012 at 4:12 PM, William A. Rowe Jr.
wrowe@rowe-clan.net wrote:
No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux
distros have moved away from it...
Ubuntu starts out with the worker threaded MPM. However when you
install the standard PHP package it switches Apache to the prefork
MPM.
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
On Mon, Feb 27, 2012 at 4:12 PM, William A. Rowe Jr.
wrowe@rowe-clan.net wrote:No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux
distros have moved away from it...Ubuntu starts out with the worker threaded MPM. However when you
install the standard PHP package it switches Apache to the prefork
MPM.Actually, the true story for performance is to kill Apache and let
Lighttpd or NginX do the job, with a pool of fcgi/fpm PHP processes
About having a ZTS mod_php inside a Worker-based Apache : I know Brian Moon
having tried that on a production host some time ago.
He shares experiences here :
http://doughboy.wordpress.com/2008/02/13/apache-worker-and-php/
Hope this helps, even if it is not a recommended architecture ;)
Julien.P
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
Actually, the true story for performance is to kill Apache and let Lighttpd
or NginX do the job, with a pool of fcgi/fpm PHP processes
I'd like to ask you whether it really makes much difference to use
Lighttpd or NginX as opposed to Apache with the worker thread MPM, but
at that point we are officially way off topic (:
I think that in terms of general architecture, and in terms of what to
do with PHP, those three options are basically the same option.
I haven't studied FPM yet as I haven't felt a need for its advertised
advantages over the traditional FastCGI support in the CGI SAPI yet.
I will check out the apache worker and PHP article, thanks.
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
I did check out the article on using worker thread MPM with PHP on
Linux. The basic argument is that since threads can reclaim memory
used and then freed by other PHP requests, while processes don't
return memory to the OS until they finally exit, there is more memory
available.
However I doubt that this can be the case when the server is at peak
utilization. When things are maxed out you will still have, say, 20
threads hitting PHP scripts that happen to be expensive in terms of
memory (let's say 50mb), and that will be roughly all the memory you
have to play with in your 1GB system.
So you're just as stuck as if you had 20 dedicated fastcgi processes,
all maxed out at 50mb already by some previous request.
The only win here is that in the average case, you can handle more
requests. But you usually can't predict in advance when the worst case
will come along. So if you permit that to happen you are risking a
slowdown or a meltdown (:
For stability a fastcgi pool of the size you know you can handle based
on studying your past memory stats still seems to be the way to go.
Actually, the true story for performance is to kill Apache and let Lighttpd
or NginX do the job, with a pool of fcgi/fpm PHP processesI'd like to ask you whether it really makes much difference to use
Lighttpd or NginX as opposed to Apache with the worker thread MPM, but
at that point we are officially way off topic (:I think that in terms of general architecture, and in terms of what to
do with PHP, those three options are basically the same option.I haven't studied FPM yet as I haven't felt a need for its advertised
advantages over the traditional FastCGI support in the CGI SAPI yet.I will check out the apache worker and PHP article, thanks.
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com