Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 29.02.2012 10:43, jpauli wrote: On Wed, Feb 29, 2012 at 9:18 AM, Pierre Joyepierre@gmail.com wrote: hi Bill, On Tue, Feb 28, 2012 at 11:29 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 2/28/2012 3:41 PM, Sebastian Bergmann wrote: On 02/28/2012 02:44 PM, Christopher Jones 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
hi Bill, On Tue, Feb 28, 2012 at 11:29 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 2/28/2012 3:41 PM, Sebastian Bergmann wrote: On 02/28/2012 02:44 PM, Christopher Jones 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On Wed, Feb 29, 2012 at 9:18 AM, Pierre Joye pierre@gmail.com wrote: hi Bill, On Tue, Feb 28, 2012 at 11:29 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 2/28/2012 3:41 PM, Sebastian Bergmann wrote: On 02/28/2012 02:44 PM, Christopher Jones 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 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
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On Mon, Feb 27, 2012 at 10:12 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On 2/27/2012 6:58 AM, jpauli wrote: 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
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 Tue, Feb 28, 2012 at 4:13 AM, jpauli jpa...@php.net wrote: On Mon, Feb 27, 2012 at 10:12 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On 2/27/2012 6:58 AM, jpauli wrote: 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On Mon, Feb 27, 2012 at 4:12 PM, William A. Rowe Jr. wr...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On Tue, Feb 28, 2012 at 3:37 PM, Tom Boutell t...@punkave.com wrote: On Mon, Feb 27, 2012 at 4:12 PM, William A. Rowe Jr. wr...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On Mon, February 27, 2012 6:46 pm, Christopher Jones wrote: On 02/27/2012 01:12 PM, William A. Rowe Jr. wrote: On 2/27/2012 6:58 AM, jpauli wrote: 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-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
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. On Tue, Feb 28, 2012 at 10:41 AM, jpauli jpa...@php.net wrote: 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 -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 2/27/2012 6:46 PM, Christopher Jones wrote: On 02/27/2012 01:12 PM, William A. Rowe Jr. wrote: On 2/27/2012 6:58 AM, jpauli wrote: 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!) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 2/28/2012 12:26 PM, Stas Malyshev wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 02/28/2012 08:51 AM, William A. Rowe Jr. wrote: On 2/27/2012 6:46 PM, Christopher Jones wrote: On 02/27/2012 01:12 PM, William A. Rowe Jr. wrote: On 2/27/2012 6:58 AM, jpauli wrote: 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!) 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: 1. 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. 2. 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.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 02/28/2012 02:44 PM, Christopher Jones 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. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
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 sebast...@php.netwrote: On 02/28/2012 02:44 PM, Christopher Jones 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. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
Am 28.02.2012 22:41, schrieb Sebastian Bergmann: On 02/28/2012 02:44 PM, Christopher Jones 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. even for apache it is a bad default i bet the are more mod_php setups taht fast-cgi/cgi signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 2/28/2012 3:41 PM, Sebastian Bergmann wrote: On 02/28/2012 02:44 PM, Christopher Jones 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 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. PHP would be a much nicer, friendly and more civilized development list if it borrowed only one phrase from the Perl community; TMTOWTDI. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 02/28/2012 02:29 PM, William A. Rowe Jr. wrote: On 2/28/2012 3:41 PM, Sebastian Bergmann wrote: On 02/28/2012 02:44 PM, Christopher Jones 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 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. 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.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
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 On Fri, Feb 24, 2012 at 10:04 PM, Richard Lynch c...@l-i-e.com wrote: On Fri, February 24, 2012 1:52 pm, Tom Boutell wrote: 2. 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-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 2/27/2012 6:58 AM, jpauli wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 02/27/2012 01:12 PM, William A. Rowe Jr. wrote: On 2/27/2012 6:58 AM, jpauli wrote: 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.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
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. 1. 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? 2. 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@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! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com update-php.sh Description: Bourne shell script -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
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 On Fri, Feb 24, 2012 at 11:52 AM, Tom Boutell t...@punkave.com wrote: 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. 1. 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? 2. 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@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! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
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.) On Fri, Feb 24, 2012 at 3:08 PM, Kris Craig kris.cr...@gmail.com wrote: 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 On Fri, Feb 24, 2012 at 11:52 AM, Tom Boutell t...@punkave.com wrote: 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. 1. 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? 2. 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@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! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
hi, On Fri, Feb 24, 2012 at 9:30 PM, Tom Boutell t...@punkave.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On Fri, Feb 24, 2012 at 3:47 PM, Pierre Joye pierre@gmail.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
Once a package has been fetched, pecl install does nothing else than: phpize, make, make install and phpize does use php-config. On Fri, Feb 24, 2012 at 9:51 PM, Tom Boutell t...@punkave.com wrote: On Fri, Feb 24, 2012 at 3:47 PM, Pierre Joye pierre@gmail.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On Fri, February 24, 2012 1:52 pm, Tom Boutell wrote: 2. 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-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
