Re: [Mod-fcgid-users] Spawning explanation
Filip Hajny a écrit : > Yes, well, my point was... if you care about shared memory, then > constrain mod_fcgid to a single PHP process only, let the PHP process > fork its own children and hope they will be able to process all > requests before mod_fcgid considers the single process busy and you > end up getting 503. > My english is not really good, so maybe I very badly explained my original problem, but all the problem is here : letting PHP do that doesn't work at all. I use this configuration for mod_fcgid : DefaultMaxClassProcessCount 1 DefaultMinClassProcessCount 1 And in the PHP wrapper : export PHP_FCGI_CHILDREN=8 So I obtain this php5-cgi processes : init(1)─┬─apache2(1591)─┬─apache2(22940)───php5-cgi(23015)─┬─php5-cgi(23017) │ │ ├─php5-cgi(23018) │ │ ├─php5-cgi(23019) │ │ ├─php5-cgi(23020) │ │ ├─php5-cgi(23021) │ │ ├─php5-cgi(23022) │ │ ├─php5-cgi(23023) │ │ └─php5-cgi(23024) I test with that PHP script : Then I launch 4 concurrent access though that script : #!/bin/sh wget http://localhost/test.php -q -O test1.log & wget http://localhost/test.php -q -O test2.log & wget http://localhost/test.php -q -O test3.log & wget http://localhost/test.php -q -O test4.log & wait Then : time ./test.sh > scrubby:~# time ./check > > real 0m21.012s > user 0m0.004s > sys 0m0.012s Or also : ab -c 4 -n 4 http://localhost/test.php > Concurrency Level: 4 > Time taken for tests: 22.2176 seconds > Complete requests: 4 > Failed requests: 0 > Write errors: 0 > Total transferred: 684 bytes > HTML transferred: 8 bytes > Requests per second: 0.18 [#/sec] (mean) > Time per request: 22002.176 [ms] (mean) > Time per request: 5500.544 [ms] (mean, across all concurrent requests) The benchmark should past 5 seconds per page, no ? The php forks are not usefull with mod_fgid, or my setup have a serious problem. Of course, if I remove PHP_FCGI_CHILDREN and increase DefaultMaxClassProcessCount, this works very well but loose all the shared memory stuff (APC, Xcache, etc) : > scrubby:~# time ./check > > real 0m5.008s > user 0m0.004s > sys 0m0.004s Olivier -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mod-fcgid-users mailing list Mod-fcgid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
Re: [Mod-fcgid-users] Spawning explanation
On 28.2.2009, at 17:27, Olivier B. wrote: > my first question was about that : it seems that fcgid will _never_ > use > this concurrent PHP instances. If there is 2 concurrent access, fcgid > will spawn an other "group" of PHP to handle that, it will not use the > first group of php instance which have idled children. So in this > groups > of PHP, there is only one php child really used. > > If it is just to keep the opcode cache after PHP die (by default all > the > 500 queries), well, just 1 fork in necessary. > Yes, well, my point was... if you care about shared memory, then constrain mod_fcgid to a single PHP process only, let the PHP process fork its own children and hope they will be able to process all requests before mod_fcgid considers the single process busy and you end up getting 503. If you do not care about shared memory, then leave out the PHP forks altogether (not setting PHP_FCGI_CHILDREN), and let mod_fcgid do its job. But it doesn't make much sense to intermix the two forking levels. -F -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mod-fcgid-users mailing list Mod-fcgid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
Re: [Mod-fcgid-users] Spawning explanation
my first question was about that : it seems that fcgid will _never_ use this concurrent PHP instances. If there is 2 concurrent access, fcgid will spawn an other "group" of PHP to handle that, it will not use the first group of php instance which have idled children. So in this groups of PHP, there is only one php child really used. If it is just to keep the opcode cache after PHP die (by default all the 500 queries), well, just 1 fork in necessary. Olivier Filip Hajny a écrit : > On 28.2.2009, at 17:05, Olivier B. wrote: > > >> Yes I was thinking that but what is the interest to share memory >> between >> processes which never run simultaneously ? >> >> > > They do. If you let PHP spawn them, they all start right away, and > keep running until you kill them. They are not killed when idle etc. > > F > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > ___ > Mod-fcgid-users mailing list > Mod-fcgid-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mod-fcgid-users mailing list Mod-fcgid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
Re: [Mod-fcgid-users] Spawning explanation
On 28.2.2009, at 17:05, Olivier B. wrote: > Yes I was thinking that but what is the interest to share memory > between > processes which never run simultaneously ? > They do. If you let PHP spawn them, they all start right away, and keep running until you kill them. They are not killed when idle etc. F -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mod-fcgid-users mailing list Mod-fcgid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
Re: [Mod-fcgid-users] Spawning explanation
Yes I was thinking that but what is the interest to share memory between processes which never run simultaneously ? Olivier Filip Hajny a écrit : > On 28.2.2009, at 15:24, Olivier B. wrote: > > >> So, I simply read the file sapi/cgi/README.FastCGI in the PHP source. >> If I well understand, this feature is usefull when you run directly >> PHP >> as the fcgi daemon. >> >> > > It's also useful when you want memory shared among the PHP processes > (e.g. for caching). It's not shared if spawned by mod_fcgid. > > -F > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > ___ > Mod-fcgid-users mailing list > Mod-fcgid-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mod-fcgid-users mailing list Mod-fcgid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
Re: [Mod-fcgid-users] Spawning explanation
On 28.2.2009, at 15:24, Olivier B. wrote: > So, I simply read the file sapi/cgi/README.FastCGI in the PHP source. > If I well understand, this feature is usefull when you run directly > PHP > as the fcgi daemon. > It's also useful when you want memory shared among the PHP processes (e.g. for caching). It's not shared if spawned by mod_fcgid. -F -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mod-fcgid-users mailing list Mod-fcgid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
Re: [Mod-fcgid-users] Spawning explanation
So, I simply read the file sapi/cgi/README.FastCGI in the PHP source. If I well understand, this feature is usefull when you run directly PHP as the fcgi daemon. I have the end of my explanation, thanks and sorry for noise ;) Olivier Olivier B. a écrit : > Max Dittrich a écrit : > >> AFAIK (?) mod_fcgid can't multiplex multiple request on one fcgi-socket. >> The fcgi-connection is 1:1 (http request <--> fcgi connection) and can't >> be shared across childs/threads of apache. >> >> .max >> >> > Ok, it is what I see too. Thanks. > > > Filip Hajny a écrit : > >> PHP forks because you tell it to. If you ever set PHP_FCGI_CHILDREN to >> anything, PHP will fork *that many* processes right away regardless of >> how many requests you receive. mod_fcgid doesn't know anything about >> this, so you're essentially spawning processes at two levels >> (mod_fcgid and PHP itself). My suggestion is to yank our >> PHP_FCGI_CHILDREN completely. Just leave the process management to >> mod_fcgid. >> >> -- >> Filip Hajny >> > Of course PHP forks because I ask to do it. But the question is why this > feature exists if it is _totally_ useless ? > I will ask on the PHP mailing list, maybe they know why they add that > strange behavior. > > Thanks. > > Olivier > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > ___ > Mod-fcgid-users mailing list > Mod-fcgid-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mod-fcgid-users mailing list Mod-fcgid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
Re: [Mod-fcgid-users] Spawning explanation
Max Dittrich a écrit : > AFAIK (?) mod_fcgid can't multiplex multiple request on one fcgi-socket. > The fcgi-connection is 1:1 (http request <--> fcgi connection) and can't > be shared across childs/threads of apache. > > .max > Ok, it is what I see too. Thanks. Filip Hajny a écrit : > PHP forks because you tell it to. If you ever set PHP_FCGI_CHILDREN to > anything, PHP will fork *that many* processes right away regardless of > how many requests you receive. mod_fcgid doesn't know anything about > this, so you're essentially spawning processes at two levels > (mod_fcgid and PHP itself). My suggestion is to yank our > PHP_FCGI_CHILDREN completely. Just leave the process management to > mod_fcgid. > > -- > Filip Hajny Of course PHP forks because I ask to do it. But the question is why this feature exists if it is _totally_ useless ? I will ask on the PHP mailing list, maybe they know why they add that strange behavior. Thanks. Olivier -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mod-fcgid-users mailing list Mod-fcgid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
Re: [Mod-fcgid-users] Spawning explanation
On 28.2.2009, at 12:10, Max Dittrich wrote: > Olivier B. wrote: >> Yes, but in that case why PHP forks ? children will never be used !? > > AFAIK (?) mod_fcgid can't multiplex multiple request on one fcgi- > socket. > The fcgi-connection is 1:1 (http request <--> fcgi connection) and > can't > be shared across childs/threads of apache. > PHP forks because you tell it to. If you ever set PHP_FCGI_CHILDREN to anything, PHP will fork *that many* processes right away regardless of how many requests you receive. mod_fcgid doesn't know anything about this, so you're essentially spawning processes at two levels (mod_fcgid and PHP itself). My suggestion is to yank our PHP_FCGI_CHILDREN completely. Just leave the process management to mod_fcgid. -- Filip Hajny -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mod-fcgid-users mailing list Mod-fcgid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
Re: [Mod-fcgid-users] Spawning explanation
Olivier B. wrote: > Yes, but in that case why PHP forks ? children will never be used !? AFAIK (?) mod_fcgid can't multiplex multiple request on one fcgi-socket. The fcgi-connection is 1:1 (http request <--> fcgi connection) and can't be shared across childs/threads of apache. .max -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mod-fcgid-users mailing list Mod-fcgid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
