CVS Account Request: pqf

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,
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, 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,
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,
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.