[PHP-DEV] Re: wiki/windows.php.net system update
Pierre Joye wrote: hi, The wiki.php.net and windows.php.net box is being updated. The sites will be back online asap. Has it been a full year since PECL for Windows was to be ready? Just asking. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 5.3.0 Released!
Lukas Kahwe Smith wrote: Hello! The PHP Development Team would like to announce the immediate release of PHP 5.3.0. This release is a major improvement in the 5.X series, which includes a large number of new features and bug fixes. Release Announcement: http://www.php.net/release/5_3_0.php Downloads:http://php.net/downloads.php#v5.3.0 Changelog:http://www.php.net/ChangeLog-5.php#5.3.0 regards, Johannes and Lukas Great ! The downloads page is devoid of any note in re pRCL binaries for Windows. windows.php.net doesn't say anything either of which pre-existing PECL binaries will work with 5_3. Is the 5_2_6 set of PECL binaries compatible with 5_3 ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: pqf
Hi, Sorry, I did not have any benchmark yet, and I don't think I can give out an objective benchmark ^_^ Thanks Thomas Seifert [EMAIL PROTECTED] news:[EMAIL PROTECTED] Hi, that sounds really interesting. Kind of a connection pool held in one group of php-processes. Did you do any benchmarks with your FCGI-implementation vs. mod_php ? TIA, thomas On Sat, 10 Jul 2004 09:22:34 +0800 [EMAIL PROTECTED] (Qingfeng Pan) wrote: Hi, all Improvement in the latest release: You can group the php scripts by the resource they are using For example: there are four PHP scripts: foo.php, bar.php, database1.php and database2.php. foo.php and bar.php are simple scripts that do not connect to database, but database1.php and database2.php do. In share mode, there is only one type of PHP fastcgi process, all .php script will be run with any free fastcgi process, so, once database*.php is called, the php fastcgi process will be polluted, and a database connection will be keep by this fastcgi php process. If all .php are running with non-share mode, all .php scripts will be run separately, This will spawn unnecessary php processes, because foo.php and bar.php can share one PHP process, database1.php and database2.php can share another. Now you can override this dilemma with the following configuration: Directory /usr/local/apache2/htdocs/php SetHandler fcgid-script FCGIWrapper /usr/local/bin/php FCGIWrapperGroup /usr/local/bin/php database1.php database2.php Options ExecCGI allow from all /Directory Now database1.php and database2.php share one group of PHP processes, and all other PHP scripts in /usr/local/apache2/htdocs/php share another. By the way, you can setup many groups with multi-FCGIWrapperGroup setting. Thanks Derick Rethans [EMAIL PROTECTED] news:[EMAIL PROTECTED] Hey, sounds cool, do you have any code to show as I'm interested in trying it out. regards, Derick On Mon, 5 Jul 2004, Qingfeng Pan wrote: There are some advantages... a) mod_fastcgi talk to PHP process with TCP socket, but this module use UNIX domain socket(or named pipe on Win32) instead. PHP with TCP socket will make Fastcgi-PHP not workable on Win32 (bug #27515 php -b still not working). With the new module, -b options is *NOT* necessary, because it's now using named-pipe on Win32. I have tested the binary Win32 Installer downloaded from official website. On the other hand, the performance is better while using UNIX domain socket on UNIX platform. With mod_fastcgi, you will have to run Fastcgi-PHP separately from the web server in UNIX box. That mean you have to start some PHP processes before Apache start, it's not a big deal, but not that pure like mod_php. b) Spawn PHP process dynamically, that mean spawn a PHP process ONLY when incoming a new request or there is no enought FastCGI process. With mod_fastcgi PHP, you have to run PHP separately and specify the PHP process number at the very beginning. c) Corrupt process detecting. With mod_fastcgi, every request is commucating throught a single TCP port, that mean the worker thread(or prefork process) of Apache does NOT know which FastCGI PHP process it's talking to. If there is something wrong with the PHP script, the worker thread knows there is a corrupt process there, but it can't tell which one is, With the new module, every fastcgi PHP process has a unique path listening on. That makes it easy to kick out the corrupt fastcgi server. Wez Furlong [EMAIL PROTECTED] news:[EMAIL PROTECTED] We already have a fastcgi module... why do we need another apache2 specific thing? --Wez. On 5 Jul 2004 05:43:47 -, Qingfeng Pan [EMAIL PROTECTED] wrote: add an Apache2 fastcgi module for PHP(fastcgi.coremail.cn), I hope it will be released with PHP 5.1 branch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: pqf
Hi, There are two other apache2 modules(apache2filterapache2handler) included in php distribution, so I did not even think about it when i submited the request... I still hope the module can be included. Thanks Wez Furlong [EMAIL PROTECTED] news:[EMAIL PROTECTED] Now, why does this apache module belong in the php distro? Shouldn't you be talking to the apache people instead? --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: pqf
Hi, all Improvement in the latest release: You can group the php scripts by the resource they are using For example: there are four PHP scripts: foo.php, bar.php, database1.php and database2.php. foo.php and bar.php are simple scripts that do not connect to database, but database1.php and database2.php do. In share mode, there is only one type of PHP fastcgi process, all .php script will be run with any free fastcgi process, so, once database*.php is called, the php fastcgi process will be polluted, and a database connection will be keep by this fastcgi php process. If all .php are running with non-share mode, all .php scripts will be run separately, This will spawn unnecessary php processes, because foo.php and bar.php can share one PHP process, database1.php and database2.php can share another. Now you can override this dilemma with the following configuration: Directory /usr/local/apache2/htdocs/php SetHandler fcgid-script FCGIWrapper /usr/local/bin/php FCGIWrapperGroup /usr/local/bin/php database1.php database2.php Options ExecCGI allow from all /Directory Now database1.php and database2.php share one group of PHP processes, and all other PHP scripts in /usr/local/apache2/htdocs/php share another. By the way, you can setup many groups with multi-FCGIWrapperGroup setting. Thanks Derick Rethans [EMAIL PROTECTED] news:[EMAIL PROTECTED] Hey, sounds cool, do you have any code to show as I'm interested in trying it out. regards, Derick On Mon, 5 Jul 2004, Qingfeng Pan wrote: There are some advantages... a) mod_fastcgi talk to PHP process with TCP socket, but this module use UNIX domain socket(or named pipe on Win32) instead. PHP with TCP socket will make Fastcgi-PHP not workable on Win32 (bug #27515 php -b still not working). With the new module, -b options is *NOT* necessary, because it's now using named-pipe on Win32. I have tested the binary Win32 Installer downloaded from official website. On the other hand, the performance is better while using UNIX domain socket on UNIX platform. With mod_fastcgi, you will have to run Fastcgi-PHP separately from the web server in UNIX box. That mean you have to start some PHP processes before Apache start, it's not a big deal, but not that pure like mod_php. b) Spawn PHP process dynamically, that mean spawn a PHP process ONLY when incoming a new request or there is no enought FastCGI process. With mod_fastcgi PHP, you have to run PHP separately and specify the PHP process number at the very beginning. c) Corrupt process detecting. With mod_fastcgi, every request is commucating throught a single TCP port, that mean the worker thread(or prefork process) of Apache does NOT know which FastCGI PHP process it's talking to. If there is something wrong with the PHP script, the worker thread knows there is a corrupt process there, but it can't tell which one is, With the new module, every fastcgi PHP process has a unique path listening on. That makes it easy to kick out the corrupt fastcgi server. Wez Furlong [EMAIL PROTECTED] news:[EMAIL PROTECTED] We already have a fastcgi module... why do we need another apache2 specific thing? --Wez. On 5 Jul 2004 05:43:47 -, Qingfeng Pan [EMAIL PROTECTED] wrote: add an Apache2 fastcgi module for PHP(fastcgi.coremail.cn), I hope it will be released with PHP 5.1 branch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: pqf
Hi, Derick Please visit http://fastcgi.coremail.cn, source code and doc there ^_^ Thanks Qingfeng Pan Derick Rethans [EMAIL PROTECTED] news:[EMAIL PROTECTED] Hey, sounds cool, do you have any code to show as I'm interested in trying it out. regards, Derick On Mon, 5 Jul 2004, Qingfeng Pan wrote: There are some advantages... a) mod_fastcgi talk to PHP process with TCP socket, but this module use UNIX domain socket(or named pipe on Win32) instead. PHP with TCP socket will make Fastcgi-PHP not workable on Win32 (bug #27515 php -b still not working). With the new module, -b options is *NOT* necessary, because it's now using named-pipe on Win32. I have tested the binary Win32 Installer downloaded from official website. On the other hand, the performance is better while using UNIX domain socket on UNIX platform. With mod_fastcgi, you will have to run Fastcgi-PHP separately from the web server in UNIX box. That mean you have to start some PHP processes before Apache start, it's not a big deal, but not that pure like mod_php. b) Spawn PHP process dynamically, that mean spawn a PHP process ONLY when incoming a new request or there is no enought FastCGI process. With mod_fastcgi PHP, you have to run PHP separately and specify the PHP process number at the very beginning. c) Corrupt process detecting. With mod_fastcgi, every request is commucating throught a single TCP port, that mean the worker thread(or prefork process) of Apache does NOT know which FastCGI PHP process it's talking to. If there is something wrong with the PHP script, the worker thread knows there is a corrupt process there, but it can't tell which one is, With the new module, every fastcgi PHP process has a unique path listening on. That makes it easy to kick out the corrupt fastcgi server. Wez Furlong [EMAIL PROTECTED] news:[EMAIL PROTECTED] We already have a fastcgi module... why do we need another apache2 specific thing? --Wez. On 5 Jul 2004 05:43:47 -, Qingfeng Pan [EMAIL PROTECTED] wrote: add an Apache2 fastcgi module for PHP(fastcgi.coremail.cn), I hope it will be released with PHP 5.1 branch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: pqf
There are some advantages... a) mod_fastcgi talk to PHP process with TCP socket, but this module use UNIX domain socket(or named pipe on Win32) instead. PHP with TCP socket will make Fastcgi-PHP not workable on Win32 (bug #27515 php -b still not working). With the new module, -b options is *NOT* necessary, because it's now using named-pipe on Win32. I have tested the binary Win32 Installer downloaded from official website. On the other hand, the performance is better while using UNIX domain socket on UNIX platform. With mod_fastcgi, you will have to run Fastcgi-PHP separately from the web server in UNIX box. That mean you have to start some PHP processes before Apache start, it's not a big deal, but not that pure like mod_php. b) Spawn PHP process dynamically, that mean spawn a PHP process ONLY when incoming a new request or there is no enought FastCGI process. With mod_fastcgi PHP, you have to run PHP separately and specify the PHP process number at the very beginning. c) Corrupt process detecting. With mod_fastcgi, every request is commucating throught a single TCP port, that mean the worker thread(or prefork process) of Apache does NOT know which FastCGI PHP process it's talking to. If there is something wrong with the PHP script, the worker thread knows there is a corrupt process there, but it can't tell which one is, With the new module, every fastcgi PHP process has a unique path listening on. That makes it easy to kick out the corrupt fastcgi server. Wez Furlong [EMAIL PROTECTED] news:[EMAIL PROTECTED] We already have a fastcgi module... why do we need another apache2 specific thing? --Wez. On 5 Jul 2004 05:43:47 -, Qingfeng Pan [EMAIL PROTECTED] wrote: add an Apache2 fastcgi module for PHP(fastcgi.coremail.cn), I hope it will be released with PHP 5.1 branch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: pqf
add an Apache2 fastcgi module for PHP(fastcgi.coremail.cn), I hope it will be released with PHP 5.1 branch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] About bug 27515 and 28343
I think the new Apache2 FastCGI module can fix the problems, the submitter should take a try... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The open letter to Derick Rethans derick@php.net
I think Fastcgi is a solution to make non-threadsafe PHP extionsion to work with Apache2... that's why I develop my Apache2 module mod_fcgid, it's available on fastcgi.coremail.cn. I think the community will not accept this module as a part of PHP now, but I will make another try when the PHP5.1 is branched. any suggestion is appreciated... Lester Caine [EMAIL PROTECTED] news:[EMAIL PROTECTED] Steph wrote: The next question is - are both PHP4 and PHP5 going to be run in parallel, like Apache 1 and 2 so that neither gets finished ;) Darn.. y'mean PHP 4 isn't finished? ;) Well is it approved for use with Apache2? -- Lester Caine - L.S.Caine Electronic Services -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH][2nd POST]sapi fastcgi check a new environment PHP_FCGI_NOFORK
It's a simple modification, and will not conflict with the previous version.
Please reconsider it...
If the environment PHP_FCGI_NOFORK is set, then now useless fastcgi processs
is spawned.
I make this patch is because my Apache2 module(http://fastcgi.coremail.cn)
work on UNIX domain socket, and don't need PHP to run with -b IP:Port mode
as external fastcgi server any more, so the extra process spawnning is not
necessary.
I think it's not the right time to summit the Apache2 module source to PHP,
because the PHP5 is releaseing in a month or two, but I hope this patch can
be committed to the PHP5 cvs branch, because it's really very simple, but
reduse the process number of fastcgi server.
I hope I can summit the Apache fastcgi module to PHP5.1 while the branche
start.
Please give me some replys, thanks :-)
Index: cgi_main.c
===
RCS file: /repository/php-src/sapi/cgi/cgi_main.c,v
retrieving revision 1.254
diff -u -r1.254 cgi_main.c
--- cgi_main.c 6 May 2004 15:41:59 - 1.254
+++ cgi_main.c 25 May 2004 06:00:18 -
@@ -1182,7 +1182,7 @@
}
}
- if( children ) {
+ if( !getenv(PHP_FCGI_NOFORK) children ) {
int running = 0;
pid_t pid;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH]An Apache2 fastcgi module
I am the guy who post this, but it seems missing my attachment? I post it
here again...
Index: cgi_main.c
===
RCS file: /repository/php-src/sapi/cgi/cgi_main.c,v
retrieving revision 1.190.2.60
diff -u -r1.190.2.60 cgi_main.c
--- cgi_main.c 31 Mar 2004 17:01:45 - 1.190.2.60
+++ cgi_main.c 21 May 2004 17:46:44 -
@@ -1197,7 +1197,7 @@
}
}
- if( children ) {
+ if( !getenv(PHP_FCGI_NOFORK) children ) {
int running = 0;
pid_t pid;
]ËáîW [EMAIL PROTECTED] дÈëÓʼþ
news:[EMAIL PROTECTED]
Hi, all
I just finished an apache2 fastcgi module: mod_fcgid, can this module be
a part of PHP?
You can find the goals for the implementation in
http://fastcgi.coremail.cn/index.htm
I have to highlight a different from mod_fastcgi: Every fastcgi process
has unique UNIX domain socket path, so the following problem will not happen
anymore(copy from README.Zeus): While we can run FastCGI's locally, there
are known problems with some OS's (specifically, the communication between
web server and FastCGI happens over a unix domain socket, and some OS's have
trouble sustaining high connection rates over these sockets),
Because fastcgi application is no more running in -b port mode while
working with mod_fcgid, so I patch sapi/cgi/cgi_main.c, check an enviroment
variable PHP_FCGI_NOFORK , if it is set, then the fork() is skipped. I
tested this patch with my module, it work fine. It's a very simple
modification, I just modified one line of the source code.
You can download the apache module source code and documentation from the
link i mention above. ( and a simple configuation demo to show how to make
fastcgi-php application work with mod_fcgid)
I would like to put this module into PHP project, can I? And if I can,
how to do it?
Thank for any comment and advice.
Qingfeng Pan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
