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