php cli question
in [General]
|
From: Per Jessen on 14 Sep 2010 16:15 J Ravi Menon wrote: > 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. >=20 > Just to clarify, you mean we don't need the op-code cache here right?= That is correct. >>> 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. >=20 > So 'unset($some_big_array)' or 'unset($some_big_object)' etc.. is th= e > right way to go for non-resource based items? i.e. it needs to be > explicitly done? It's not quite like C - if you reassign something, the previous content= s are automagically freed. I use unset() if I know it could be a while (hours) before it'll likely be reassigned, but it won't be used in the meantime.=20 --=20 Per Jessen, Z=C3=BCrich (14.6=C2=B0C)
From: Nathan Rixham on 14 Sep 2010 22:01 Per Jessen wrote: > J Ravi Menon wrote: >>>> 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? > > It's not quite like C - if you reassign something, the previous contents > are automagically freed. I use unset() if I know it could be a while > (hours) before it'll likely be reassigned, but it won't be used in the > meantime. Has anybody done a comparison of setting to null rather than unset'ing; does unset invoke the garbage collector instantly? i.e. is unset the best approach to clearing objects from memory quickly? Best, Nathan
From: J Ravi Menon on 14 Sep 2010 22:19 On Tue, Sep 14, 2010 at 1:15 PM, Per Jessen <per(a)computer.org> wrote: > J Ravi Menon wrote: > >> 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? > > That is correct. > >>>> 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? > > It's not quite like C - if you reassign something, the previous contents > are automagically freed. I use unset() if I know it could be a while > (hours) before it'll likely be reassigned, but it won't be used in the > meantime. > Thanks Per for clarifying this for me. Now on my follow up question: [Note: I think it is related to the issues discussed above hence keeping it on this thread but if I am violating any guidelines here, do let me know] One reason the aforesaid questions got triggered was that in our company right now, there is a big discussion on moving away from apache+mod_php solution to nginx+fast-cgi based model for handling all php-based services. The move seems to be more based some anecdotal observations and possibly not based on a typical php-based app (i.e. the php script involved was trivial one acting as some proxy to another backend service). I have written fast-cgi servers in the past in C++, and I am aware how the apahce<---->fast-cgi-servers work (in unix socket setups). All our php apps are written with apache+mod_php in mind (no explicit resource mgmt ), so this was a concern to me. If the same scripts now need to run 'forever' as a fastcgi server, are we forced to do such manual resource mgmt? Or are there solutions here that work just as in mod_php? This reminded me of the cli daemons that I had written earlier where such manual cleanups were done, and hence my doubts on this nginx+fast-cgi approach. thx, Ravi > > > -- > Per Jessen, Zürich (14.6°C) > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
From: Bostjan Skufca on 15 Sep 2010 05:38 Here are the results I got when question of migration from apache to nginx was brought up: http://blog.a2o.si/2009/06/24/apache-mod_php-compared-to-nginx-php-fpm/ (BTW there is some FPM in main PHP distribution now) As for resource management, I recommend looking at php sources (Zend/zend_alloca.c:zend_mm_shutdown() specifically) and building a custom extension that frees discarded memory resources on your request or timer or sth else. Not sure if it is possible like that but this is just a suggestion, don't quote me on that :) Also, for such questions I recommend you to join php-internals mailing list, it seems more appropriate. b. On 15 September 2010 04:19, J Ravi Menon <jravimenon(a)gmail.com> wrote: > On Tue, Sep 14, 2010 at 1:15 PM, Per Jessen <per(a)computer.org> wrote: > > J Ravi Menon wrote: > > > >> 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? > > > > That is correct. > > > >>>> 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? > > > > It's not quite like C - if you reassign something, the previous contents > > are automagically freed. I use unset() if I know it could be a while > > (hours) before it'll likely be reassigned, but it won't be used in the > > meantime. > > > > Thanks Per for clarifying this for me. Now on my follow up question: > > [Note: I think it is related to the issues discussed above hence > keeping it on this thread but if I am violating any guidelines here, > do let me know] > > One reason the aforesaid questions got triggered was that in our > company right now, there is a big discussion on moving away from > apache+mod_php solution to nginx+fast-cgi based model for handling all > php-based services. The move seems to be more based some anecdotal > observations and possibly not based on a typical php-based app (i.e. > the php script involved was trivial one acting as some proxy to > another backend service). > > I have written fast-cgi servers in the past in C++, and I am aware how > the apahce<---->fast-cgi-servers work (in unix socket setups). All > our php apps are written with apache+mod_php in mind (no explicit > resource mgmt ), so this was a concern to me. > > If the same scripts now need to run 'forever' as a fastcgi server, are > we forced to do such manual resource mgmt? Or are there solutions here > that work just as in mod_php? > > This reminded me of the cli daemons that I had written earlier where > such manual cleanups were done, and hence my doubts on this > nginx+fast-cgi approach. > > thx, > Ravi > > > > > > > > -- > > Per Jessen, Zürich (14.6°C) > > > > > > -- > > PHP General Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
From: J Ravi Menon on 15 Sep 2010 16:22
Thanks Bostjan for the suggestion. I did raise the issue and here is the reply: http://news.php.net/php.internals/49672 Thx, Ravi On Wed, Sep 15, 2010 at 2:38 AM, Bostjan Skufca <bostjan(a)a2o.si> wrote: > Here are the results I got when question of migration from apache to nginx > was brought up: > http://blog.a2o.si/2009/06/24/apache-mod_php-compared-to-nginx-php-fpm/ > (BTW there is some FPM in main PHP distribution now) > > As for resource management, I recommend looking at php sources > (Zend/zend_alloca.c:zend_mm_shutdown() specifically) and building a custom > extension that frees discarded memory resources on your request or timer or > sth else. Not sure if it is possible like that but this is just a > suggestion, don't quote me on that :) > Also, for such questions I recommend you to join php-internals mailing list, > it seems more appropriate. > > b. > > > On 15 September 2010 04:19, J Ravi Menon <jravimenon(a)gmail.com> wrote: >> >> On Tue, Sep 14, 2010 at 1:15 PM, Per Jessen <per(a)computer.org> wrote: >> > J Ravi Menon wrote: >> > >> >> 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? >> > >> > That is correct. >> > >> >>>> 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? >> > >> > It's not quite like C - if you reassign something, the previous contents >> > are automagically freed. I use unset() if I know it could be a while >> > (hours) before it'll likely be reassigned, but it won't be used in the >> > meantime. >> > >> >> Thanks Per for clarifying this for me. Now on my follow up question: >> >> [Note: I think it is related to the issues discussed above hence >> keeping it on this thread but if I am violating any guidelines here, >> do let me know] >> >> One reason the aforesaid questions got triggered was that in our >> company right now, there is a big discussion on moving away from >> apache+mod_php solution to nginx+fast-cgi based model for handling all >> php-based services. The move seems to be more based some anecdotal >> observations and possibly not based on a typical php-based app (i.e. >> the php script involved was trivial one acting as some proxy to >> another backend service). >> >> I have written fast-cgi servers in the past in C++, and I am aware how >> the apahce<---->fast-cgi-servers work (in unix socket setups). All >> our php apps are written with apache+mod_php in mind (no explicit >> resource mgmt ), so this was a concern to me. >> >> If the same scripts now need to run 'forever' as a fastcgi server, are >> we forced to do such manual resource mgmt? Or are there solutions here >> that work just as in mod_php? >> >> This reminded me of the cli daemons that I had written earlier where >> such manual cleanups were done, and hence my doubts on this >> nginx+fast-cgi approach. >> >> thx, >> Ravi >> >> >> > >> > >> > -- >> > Per Jessen, Zürich (14.6°C) >> > >> > >> > -- >> > PHP General Mailing List (http://www.php.net/) >> > To unsubscribe, visit: http://www.php.net/unsub.php >> > >> > >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > |