php cli question
in [General]
|
From: J Ravi Menon on 10 Sep 2010 12:13 Hi, I have some basic questions on running php (5.2.x series on Linux 2.6) as a standalone daemon using posix methods (fork() etc..): #!/usr/bin/php <?php require_once ('someclass.php'); // do some initializations .. // main 'forever' loop - the '$shutdown' will // be set to true via a signal handler while(!$shutdown) { $a = new SomeClass(); $a->doSomething() } // shutdown logic. The 'someclass.php' in turn will include other files (via require_once). The above file will be executed directly from the shell. The main loop could be listening to new requests via sockets etc.. Few questions: 1) Does opcode cache really matter in such cli-based daemons? As 'SomeClass' is instantiated at every loop, I am assuming it is only compiled once as it has already been 'seen'. I am not very clear on how apc (or eaccelerator) works in such cases. 2) What about garbage collection? In a standard apache-mod-php setup, we rely on the end of a request-cycle to free up resources - close file descriptiors, free up memory etc.. I am assuming in the aforesaid standalone daemon case, we would have to do this manually? In the loop above, would it be better to 'unset($a)' explicitly at the end of it before it goes to the next iteration? Note: I have written pre-forker deamons in php directly and successfully deployed them in the past, but never looked at in depth to understand all the nuances. Anecdotally, I have done 'unset()' at some critical places were large arrays were used, and I think it helped. AFAIK, unlike Java, there is no 'garbage collector' thread that does all the magic? Thanks, Ravi
From: Shawn McKenzie on 11 Sep 2010 23:50 On 09/10/2010 11:13 AM, J Ravi Menon wrote: > Hi, > > I have some basic questions on running php (5.2.x series on Linux > 2.6) as a standalone daemon using posix methods (fork() etc..): > > #!/usr/bin/php > <?php > > require_once ('someclass.php'); > > // do some initializations > . > > // main 'forever' loop - the '$shutdown' will > // be set to true via a signal handler > > while(!$shutdown) > { > $a = new SomeClass(); > > $a->doSomething() > > } > > // shutdown logic. > > The 'someclass.php' in turn will include other files (via require_once). > > The above file will be executed directly from the shell. The main loop > could be listening to new requests via sockets etc.. > > Few questions: > > 1) Does opcode cache really matter in such cli-based daemons? As > 'SomeClass' is instantiated at every loop, I am assuming it is only > compiled once as it has already been 'seen'. > I am not very clear on how apc (or eaccelerator) works in such cases. > > > 2) What about garbage collection? In a standard apache-mod-php setup, > we rely on the end of a request-cycle to free up resources - close > file descriptiors, free up memory etc.. > I am assuming in the aforesaid standalone daemon case, we would > have to do this manually? In the loop above, would it be better to > 'unset($a)' explicitly at the end of it before > it goes to the next iteration? > > Note: I have written pre-forker deamons in php directly and > successfully deployed them in the past, but never looked at in depth > to understand all the nuances. Anecdotally, I have > done 'unset()' at some critical places were large arrays were used, > and I think it helped. AFAIK, unlike Java, there is no 'garbage > collector' thread that does all the magic? > > Thanks, > Ravi If I have time when you reply I'll answer the questions, but I must ask: Is this purely academic? Why is this a concern? Have you encountered issues? If so, what? -- Thanks! -Shawn http://www.spidean.com
From: J Ravi Menon on 13 Sep 2010 15:01 On Sat, Sep 11, 2010 at 8:50 PM, Shawn McKenzie <nospam(a)mckenzies.net> wrote: > On 09/10/2010 11:13 AM, J Ravi Menon wrote: >> Hi, >> >> I have some basic questions on running php (5.2.x series on Linux >> 2.6) as a standalone daemon using posix methods (fork() etc..): >> >> #!/usr/bin/php >> <?php >> >> require_once ('someclass.php'); >> >> // do some initializations >> . >> >> // main 'forever' loop - the '$shutdown' will >> // be set to true via a signal handler >> >> while(!$shutdown) >> { >> $a = new SomeClass(); >> >> $a->doSomething() >> >> } >> >> // shutdown logic. >> >> The 'someclass.php' in turn will include other files (via require_once). >> >> The above file will be executed directly from the shell. The main loop >> could be listening to new requests via sockets etc.. >> >> Few questions: >> >> 1) Does opcode cache really matter in such cli-based daemons? As >> 'SomeClass' is instantiated at every loop, I am assuming it is only >> compiled once as it has already been 'seen'. >> I am not very clear on how apc (or eaccelerator) works in such cases. >> >> >> 2) What about garbage collection? In a standard apache-mod-php setup, >> we rely on the end of a request-cycle to free up resources - close >> file descriptiors, free up memory etc.. >> I am assuming in the aforesaid standalone daemon case, we would >> have to do this manually? In the loop above, would it be better to >> 'unset($a)' explicitly at the end of it before >> it goes to the next iteration? >> >> Note: I have written pre-forker deamons in php directly and >> successfully deployed them in the past, but never looked at in depth >> to understand all the nuances. Anecdotally, I have >> done 'unset()' at some critical places were large arrays were used, >> and I think it helped. AFAIK, unlike Java, there is no 'garbage >> collector' thread that does all the magic? >> >> Thanks, >> Ravi > > If I have time when you reply I'll answer the questions, but I must ask: > Is this purely academic? Why is this a concern? Have you encountered > issues? If so, what? @Tom: I have compiled php with pcntl on and this has never been an issue. It works well (on a linux setup), and I have deployed standalone daemons with out any major problems. I have a home-grown 'preforker' framework (which I hope to share soon) which can be used to exploit multi-core boxes. @Shawn: It is not academic. There is a follow-up I am planning based on the doubts above. I have deployed such daemons in the past with some assumptions on (2) by doing manual cleanups - e.g. closing curl connections, closing up db handles etc... Really want to understand how php works in such setups outside of apache+mod_php. thanks, Ravi > > -- > Thanks! > -Shawn > http://www.spidean.com >
From: Per Jessen on 14 Sep 2010 03:43 J Ravi Menon wrote: > Few questions: >=20 > 1) Does opcode cache really matter in such cli-based daemons? As > 'SomeClass' is instantiated at every loop, I am assuming it is only > compiled once as it has already been 'seen'. Yup. > 2) What about garbage collection? In a standard apache-mod-php setup,= > we rely on the end of a request-cycle to free up resources - close > file descriptiors, free up memory etc.. > I am assuming in the aforesaid standalone daemon case, we would > have to do this manually? =20 Yes. > Note: I have written pre-forker deamons in php directly and > successfully deployed them in the past, but never looked at in depth > to understand all the nuances. Anecdotally, I have > done 'unset()' at some critical places were large arrays were used, > and I think it helped. AFAIK, unlike Java, there is no 'garbage > collector' thread that does all the magic? Correct. --=20 Per Jessen, Z=C3=BCrich (12.9=C2=B0C)
From: J Ravi Menon on 14 Sep 2010 13:35
On Tue, Sep 14, 2010 at 12:43 AM, Per Jessen <per(a)computer.org> wrote: > J Ravi Menon wrote: > >> Few questions: >> >> 1) Does opcode cache really matter in such cli-based daemons? As >> 'SomeClass' is instantiated at every loop, I am assuming it is only >> compiled once as it has already been 'seen'. > > Yup. Just to clarify, you mean we don't need the op-code cache here right? > >> 2) What about garbage collection? In a standard apache-mod-php setup, >> we rely on the end of a request-cycle to free up resources - close >> file descriptiors, free up memory etc.. >> I am assuming in the aforesaid standalone daemon case, we would >> have to do this manually? > > Yes. > So 'unset($some_big_array)' or 'unset($some_big_object)' etc.. is the right way to go for non-resource based items? i.e. it needs to be explicitly done? thx, Ravi >> Note: I have written pre-forker deamons in php directly and >> successfully deployed them in the past, but never looked at in depth >> to understand all the nuances. Anecdotally, I have >> done 'unset()' at some critical places were large arrays were used, >> and I think it helped. AFAIK, unlike Java, there is no 'garbage >> collector' thread that does all the magic? > > Correct. > > > > -- > Per Jessen, Zürich (12.9°C) > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > |