add an Apache2 fastcgi module for PHP(fastcgi.coremail.cn), I hope it will be released with PHP 5.1 branch
We already have a fastcgi module... why do we need another apache2
specific thing?
--Wez.
add an Apache2 fastcgi module for PHP(fastcgi.coremail.cn), I hope it will be released with PHP 5.1 branch
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" kingwez@gmail.com ????
news:4e89b4260407050538460acfee@mail.gmail.com...
We already have a fastcgi module... why do we need another apache2
specific thing?--Wez.
add an Apache2 fastcgi module for PHP(fastcgi.coremail.cn), I hope it
will be released with PHP 5.1 branch
Hey,
sounds cool, do you have any code to show as I'm interested in trying it
out.
regards,
Derick
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" kingwez@gmail.com ????
news:4e89b4260407050538460acfee@mail.gmail.com...We already have a fastcgi module... why do we need another apache2
specific thing?--Wez.
add an Apache2 fastcgi module for PHP(fastcgi.coremail.cn), I hope it
will be released with PHP 5.1 branch
Hi, Derick
Please visit http://fastcgi.coremail.cn, source code and doc there ^_^
Thanks
Qingfeng Pan
"Derick Rethans" derick@php.net ????
news:Pine.LNX.4.58.0407080931160.11582@localhost...
Hey,
sounds cool, do you have any code to show as I'm interested in trying it
out.regards,
DerickThere 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" kingwez@gmail.com ????
news:4e89b4260407050538460acfee@mail.gmail.com...We already have a fastcgi module... why do we need another apache2
specific thing?--Wez.
add an Apache2 fastcgi module for PHP(fastcgi.coremail.cn), I hope
it
will be released with PHP 5.1 branch
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" derick@php.net ????
news:Pine.LNX.4.58.0407080931160.11582@localhost...
Hey,
sounds cool, do you have any code to show as I'm interested in trying it
out.regards,
DerickThere 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" kingwez@gmail.com ????
news:4e89b4260407050538460acfee@mail.gmail.com...We already have a fastcgi module... why do we need another apache2
specific thing?--Wez.
add an Apache2 fastcgi module for PHP(fastcgi.coremail.cn), I hope
it
will be released with PHP 5.1 branch
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
pqf@tebie.com (Qingfeng Pan) wrote:
Hi, all
Improvement in the latest release:
You can group the php scripts by the resource they are usingFor 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" derick@php.net ????
news:Pine.LNX.4.58.0407080931160.11582@localhost...Hey,
sounds cool, do you have any code to show as I'm interested in trying it
out.regards,
DerickThere 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" kingwez@gmail.com ????
news:4e89b4260407050538460acfee@mail.gmail.com...We already have a fastcgi module... why do we need another apache2
specific thing?--Wez.
add an Apache2 fastcgi module for PHP(fastcgi.coremail.cn), I hope
it
will be released with PHP 5.1 branch
Hi,
Sorry, I did not have any benchmark yet, and I don't think I can give
out an objective benchmark ^_^
Thanks
"Thomas Seifert" thomas-lists@mysnip.de ????
news:20040710132858.536410cb.thomas-lists@mysnip.de...
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
pqf@tebie.com (Qingfeng Pan) wrote:Hi, all
Improvement in the latest release:
You can group the php scripts by the resource they are usingFor 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" derick@php.net ????
news:Pine.LNX.4.58.0407080931160.11582@localhost...Hey,
sounds cool, do you have any code to show as I'm interested in trying
it
out.regards,
DerickThere 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" kingwez@gmail.com ????
news:4e89b4260407050538460acfee@mail.gmail.com...We already have a fastcgi module... why do we need another apache2
specific thing?--Wez.
add an Apache2 fastcgi module for PHP(fastcgi.coremail.cn), I
hope
it
will be released with PHP 5.1 branch
Now, why does this apache module belong in the php distro?
Shouldn't you be talking to the apache people instead?
--Wez.
Hi,
There are two other apache2 modules(apache2filter&apache2handler)
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" kingwez@gmail.com ????
news:4e89b42604071006324b460865@mail.gmail.com...
Now, why does this apache module belong in the php distro?
Shouldn't you be talking to the apache people instead?
--Wez.
Hi,
There are two other apache2 modules(apache2filter&apache2handler)
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.
Hi,
not to be misinterpreted as I really like your module,
but its not only php-related its apache-related and could be used
for many more languages/apps than only php.
Also it would be probably more widespread if used as "general-purpose"
with better support for php as a feature.
Thomas