# CVS Account Request: pqf - Thread: https://externals.io/message/10899 - Original archive: https://news-web.php.net/php.internals/10899 - Started by Qingfeng Pan on 2004-07-05T05:43:47+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #10899 — Qingfeng Pan — 2004-07-05T05:43:47+00:00 URL: https://externals.io/message/10899#10899 add an Apache2 fastcgi module for PHP(fastcgi.coremail.cn), I hope it will be released with PHP 5.1 branch --- ## #10906 — Wez Furlong — 2004-07-05T12:38:41+00:00 URL: https://externals.io/message/10899#10906 · In reply to: #10899 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 --- ## #10909 — Qingfeng Pan — 2004-07-05T14:14:18+00:00 URL: https://externals.io/message/10899#10909 · In reply to: #10906 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" ???? news:4e89b4260407050538460acfee@mail.gmail.com... > We already have a fastcgi module... why do we need another apache2 > specific thing? > > --Wez. > > > > […] will be released with PHP 5.1 branch --- ## #10971 — Derick Rethans — 2004-07-08T07:31:41+00:00 URL: https://externals.io/message/10899#10971 · In reply to: #10909 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" ???? > news:4e89b4260407050538460acfee@mail.gmail.com... > > […] > will be released with PHP 5.1 branch --- ## #10972 — Pan qingfeng — 2004-07-08T07:47:14+00:00 URL: https://externals.io/message/10899#10972 · In reply to: #10971 Hi, Derick Please visit http://fastcgi.coremail.cn, source code and doc there ^_^ Thanks Qingfeng Pan "Derick Rethans" ???? 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 > > > > > > […] will > > […] it's > > […] the > > […] mod_php. > > […] when > > […] process > > […] commucating > > […] process) > > […] there > > […] a > > […] it > > […] --- ## #11058 — Qingfeng Pan — 2004-07-10T01:22:34+00:00 URL: https://externals.io/message/10899#11058 · In reply to: #10971 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: SetHandler fcgid-script FCGIWrapper /usr/local/bin/php FCGIWrapperGroup /usr/local/bin/php database1.php database2.php Options ExecCGI allow from all 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" ???? 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 > > > > > > […] will > > […] it's > > […] the > > […] mod_php. > > […] when > > […] process > > […] commucating > > […] process) > > […] there > > […] a > > […] it > > […] --- ## #11066 — Thomas Seifert — 2004-07-10T11:28:58+00:00 URL: https://externals.io/message/10899#11066 · In reply to: #11058 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 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: > > > SetHandler fcgid-script > FCGIWrapper /usr/local/bin/php > FCGIWrapperGroup /usr/local/bin/php database1.php database2.php > Options ExecCGI > allow from all > > > 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" ???? > news:Pine.LNX.4.58.0407080931160.11582@localhost... > > […] > will > > […] > it's > > […] > the > > […] > mod_php. > > […] > when > > […] > process > > […] > commucating > > […] > process) > > […] > there > > […] > a > > […] > it > > […] --- ## #11072 — Wez Furlong — 2004-07-10T13:32:05+00:00 URL: https://externals.io/message/10899#11072 · In reply to: #10909 Now, why does this apache module belong in the php distro? Shouldn't you be talking to the apache people instead? --Wez. --- ## #11077 — Qingfeng Pan — 2004-07-10T16:20:30+00:00 URL: https://externals.io/message/10899#11077 · In reply to: #11066 Hi, Sorry, I did not have any benchmark yet, and I don't think I can give out an objective benchmark ^_^ Thanks "Thomas Seifert" ???? 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: > > > […] and > > […] connect > > […] is > > […] run > > […] and > > […] share > > […] and > > […] setting. > > […] it > > […] use > > […] socket > > […] because > > […] Installer > > […] domain > > […] from > > […] processes > > […] If > > […] there is > > […] server. > > […] hope > > […] --- ## #11078 — Qingfeng Pan — 2004-07-10T16:29:15+00:00 URL: https://externals.io/message/10899#11078 · In reply to: #11072 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" ???? 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. --- ## #11079 — Thomas Seifert — 2004-07-10T16:39:02+00:00 URL: https://externals.io/message/10899#11079 · In reply to: #11078 > 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