From: Per Jessen on
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
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
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
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
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
>>
>
>