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