Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #7520 > unrolled thread

php daemon

Back to article view | Back to comp.lang.php

Contents

  php daemon "sl@exabyte" <sb5309@hotmail.com> - 2012-11-12 01:18 +0800
    Re: php daemon Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-11 14:04 -0500
      Re: php daemon Christoph Becker <cmbecker69@gmx.de> - 2012-11-11 21:05 +0100
        Re: php daemon Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-11 15:35 -0500
          Re: php daemon Christoph Becker <cmbecker69@gmx.de> - 2012-11-11 22:22 +0100
            Re: php daemon Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-11 16:36 -0500
              Re: php daemon Christoph Becker <cmbecker69@gmx.de> - 2012-11-11 23:17 +0100
                Re: php daemon Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-11 18:11 -0500
                  Re: php daemon Christoph Becker <cmbecker69@gmx.de> - 2012-11-12 14:35 +0100
                    Re: php daemon Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-12 08:38 -0500
                    Re: php daemon Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-13 07:44 -0500
                      Re: php daemon Christoph Becker <cmbecker69@gmx.de> - 2012-11-14 21:19 +0100
                        Re: php daemon Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-14 16:33 -0500
                          Re: php daemon Christoph Becker <cmbecker69@gmx.de> - 2012-11-14 23:13 +0100
                            Re: php daemon Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-15 07:41 -0500
                              Re: php daemon Christoph Becker <cmbecker69@gmx.de> - 2012-11-15 16:55 +0100
      Re: php daemon "sl@exabyte" <sb5309@hotmail.com> - 2012-11-12 23:45 +0800
        Re: php daemon The Natural Philosopher <tnp@invalid.invalid> - 2012-11-12 16:08 +0000
    Re: php daemon Goran <goran@nospam.com> - 2012-11-13 08:57 +0100
      Re: php daemon Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-13 07:47 -0500
        Re: php daemon Goran <goran@nospam.com> - 2012-11-13 14:54 +0100
          Re: php daemon The Natural Philosopher <tnp@invalid.invalid> - 2012-11-13 14:13 +0000
          Re: php daemon Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-13 12:23 -0500
            Re: php daemon Goran <goran@nospam.com> - 2012-11-14 08:43 +0100
              Re: php daemon Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-14 05:51 -0500
                Re: php daemon Goran <goran@nospam.com> - 2012-11-15 14:08 +0100
                  Re: php daemon Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-15 08:46 -0500
                    Re: php daemon Goran <goran@nospam.com> - 2012-11-15 16:09 +0100
                      Re: php daemon Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-15 11:25 -0500
                    Re: php daemon Tim Streater <timstreater@greenbee.net> - 2012-11-15 16:20 +0000

Page 1 of 2  [1] 2  Next page →

#7520 — php daemon

Anybody has experience of running php program as daemon ?

Would explicitly allocating and de-allocating all variables/memories be 
effective for managing php daemon ?

Thanks. 

[toc] | [next] | [standalone]

#7522

On 11/11/2012 12:18 PM, sl@exabyte wrote:
> Anybody has experience of running php program as daemon ?
>
> Would explicitly allocating and de-allocating all variables/memories be
> effective for managing php daemon ?
>
> Thanks.
>
>

Personally, I don't think PHP would make a good daemon.  Among other 
things, you cannot manage memory yourself.  All you can do is unset() 
variables.  However, this does not release memory immediately.  It would 
wait for the garbage collector to run.

When I'm writing daemons, I use C or C++.  They are much more 
appropriate, IMHO.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7523

Jerry Stuckle wrote:
> All you can do is unset() variables.  However, this does not release
> memory immediately.  It would wait for the garbage collector to run.

I'm very much surprised.  I /assumed/ that PHP uses reference counting,
which would typically release the allocated memory as soon as the
reference count of a value is 0.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#7524

On 11/11/2012 3:05 PM, Christoph Becker wrote:
> Jerry Stuckle wrote:
>> All you can do is unset() variables.  However, this does not release
>> memory immediately.  It would wait for the garbage collector to run.
>
> I'm very much surprised.  I /assumed/ that PHP uses reference counting,
> which would typically release the allocated memory as soon as the
> reference count of a value is 0.
>

It does.  But memory is not released until the garbage collector is run. 
  See the PHP documentation.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7525

Jerry Stuckle wrote:
> On 11/11/2012 3:05 PM, Christoph Becker wrote:
>> Jerry Stuckle wrote:
>>> All you can do is unset() variables.  However, this does not release
>>> memory immediately.  It would wait for the garbage collector to run.
>>
>> I'm very much surprised.  I /assumed/ that PHP uses reference counting,
>> which would typically release the allocated memory as soon as the
>> reference count of a value is 0.
>>
> 
> It does.  But memory is not released until the garbage collector is run.
>  See the PHP documentation.

Thanks for the pointer to the PHP documentation.  According to
<http://php.net/manual/en/features.gc.refcounting-basics.php>:

| A PHP variable is stored in a container called a "zval". A zval
| container contains, besides the variable's type and value, two
| additional bits of information.
| [...]
| Variable containers get destroyed when the "refcount" reaches zero.
| [...]
| Again, when the "refcount" reaches zero, the variable container is
| removed from memory.

As this simple reference counting garbage collection isn't able to free
circular structures, a garbage collector [1] to do so was introduced in
PHP 5.3.  Unfortunately the documentation isn't particularly clear here:

| If the refcount is decreased and hits zero, the zval can be freed.

But from the subsequent documentation I conclude, that the zval is
actually freed, when the refcount is decreased to zero.

[1] <http://www.php.net/manual/en/features.gc.collecting-cycles.php

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#7526

On 11/11/2012 4:22 PM, Christoph Becker wrote:
> Jerry Stuckle wrote:
>> On 11/11/2012 3:05 PM, Christoph Becker wrote:
>>> Jerry Stuckle wrote:
>>>> All you can do is unset() variables.  However, this does not release
>>>> memory immediately.  It would wait for the garbage collector to run.
>>>
>>> I'm very much surprised.  I /assumed/ that PHP uses reference counting,
>>> which would typically release the allocated memory as soon as the
>>> reference count of a value is 0.
>>>
>>
>> It does.  But memory is not released until the garbage collector is run.
>>   See the PHP documentation.
>
> Thanks for the pointer to the PHP documentation.  According to
> <http://php.net/manual/en/features.gc.refcounting-basics.php>:
>
> | A PHP variable is stored in a container called a "zval". A zval
> | container contains, besides the variable's type and value, two
> | additional bits of information.
> | [...]
> | Variable containers get destroyed when the "refcount" reaches zero.
> | [...]
> | Again, when the "refcount" reaches zero, the variable container is
> | removed from memory.
>
> As this simple reference counting garbage collection isn't able to free
> circular structures, a garbage collector [1] to do so was introduced in
> PHP 5.3.  Unfortunately the documentation isn't particularly clear here:
>
> | If the refcount is decreased and hits zero, the zval can be freed.
>
> But from the subsequent documentation I conclude, that the zval is
> actually freed, when the refcount is decreased to zero.
>
> [1] <http://www.php.net/manual/en/features.gc.collecting-cycles.php
>

No, that is the purpose of the garbage collector - which runs 
occasionally at times determined by the php.ini file.

Notice the documentation says the zval CAN be freed - not the zval WILL 
be freed.  Two entirely different statements.

This is for performance reasons.  It is much more to the running script 
efficient to free a group of unused pieces of memory asynchronously than 
to free the memory synchronously (every time the refcount goes to zero).

Note that PHP is not the only language to do it this way.  Java does 
also, for instance.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7527

Jerry Stuckle wrote:
> Notice the documentation says the zval CAN be freed - not the zval WILL
> be freed.  Two entirely different statements.

ACK.  I had noted that; therefore I wrote that the manual isn't very
clear in this (IMO important) regard.  "can" does neither imply nor
exclude, that it "will" be done.

I've made the following test:

$a = uniqid(); // force dynamic memory allocation
echo memory_get_usage(), "\n";
$a = 'foo'; // don't unset($a), as this will change the "symbol table"
echo memory_get_usage(), "\n";
gc_collect_cycles(); // force garbage collection
echo memory_get_usage(), "\n";

The result with my PHP 5.4.7 on Windows XP:

121344
121304
121304

So either the zval holding the result of uniqid() is already freed, when
$a is set to 'foo', or gc_collect_cycles() doesn't actually trigger the
garbage collector in this case.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#7528

On 11/11/2012 5:17 PM, Christoph Becker wrote:
> Jerry Stuckle wrote:
>> Notice the documentation says the zval CAN be freed - not the zval WILL
>> be freed.  Two entirely different statements.
>
> ACK.  I had noted that; therefore I wrote that the manual isn't very
> clear in this (IMO important) regard.  "can" does neither imply nor
> exclude, that it "will" be done.
>
> I've made the following test:
>
> $a = uniqid(); // force dynamic memory allocation
> echo memory_get_usage(), "\n";
> $a = 'foo'; // don't unset($a), as this will change the "symbol table"
> echo memory_get_usage(), "\n";
> gc_collect_cycles(); // force garbage collection
> echo memory_get_usage(), "\n";
>
> The result with my PHP 5.4.7 on Windows XP:
>
> 121344
> 121304
> 121304
>
> So either the zval holding the result of uniqid() is already freed, when
> $a is set to 'foo', or gc_collect_cycles() doesn't actually trigger the
> garbage collector in this case.
>

Or, memory_get_usage() does not count memory which has been marked as 
unused but not freed yet.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7531

Jerry Stuckle wrote:
> Or, memory_get_usage() does not count memory which has been marked as
> unused but not freed yet.

Indeed, that's another possibility.  But then the documentation would be
misleading:

| memory_get_usage — Returns the amount of memory allocated to PHP

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#7533

On 11/12/2012 8:35 AM, Christoph Becker wrote:
> Jerry Stuckle wrote:
>> Or, memory_get_usage() does not count memory which has been marked as
>> unused but not freed yet.
>
> Indeed, that's another possibility.  But then the documentation would be
> misleading:
>
> | memory_get_usage — Returns the amount of memory allocated to PHP
>

If you think the documentation is misleading then you should file a bug 
report.  I don't think you'll get too far, but you can try.

Personally, I find it quite clear as to what happens.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7544

On 11/12/2012 8:35 AM, Christoph Becker wrote:
> Jerry Stuckle wrote:
>> Or, memory_get_usage() does not count memory which has been marked as
>> unused but not freed yet.
>
> Indeed, that's another possibility.  But then the documentation would be
> misleading:
>
> | memory_get_usage — Returns the amount of memory allocated to PHP
>

I thought of something else you may be misunderstanding.  This is NOT 
the amount of memory allocated to PHP by the OS.  That is in multiples 
of 4K blocks (for Intel architecture).  It is the amount actually 
allocated for use by PHP.  Once that figure reaches the maximum memory 
defined in the php.ini file, no more memory can be allocated by the 
script.

Your interpretation would provide pretty worthless information as it 
would not give a true account of memory being used.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7554

Jerry Stuckle wrote:
> I thought of something else you may be misunderstanding.  This is NOT
> the amount of memory allocated to PHP by the OS.  That is in multiples
> of 4K blocks (for Intel architecture).  It is the amount actually
> allocated for use by PHP.  Once that figure reaches the maximum memory
> defined in the php.ini file, no more memory can be allocated by the script.

I'm aware of the $real_usage parameter of memory_get_usage() and the
different results reported according to the value of this parameter.
And I assume, that the following invariant holds:

    memory_get_usage(true) >= memory_get_usage(false)

> Your interpretation would provide pretty worthless information as it
> would not give a true account of memory being used.

Isn't the true amount of memory being used by PHP (independent on how
much is allocated by the OS) the relevant information for the given test?

However, reading
<http://www.php.net/manual/en/features.gc.collecting-cycles.php> and
<https://wiki.php.net/internals/zend_mm> still let's me assume, that
zvals which refcount drops to zero are immediately freed (/not
necessarily given back to the OS, though/).  The following test
/supports/ my assumption (it's no prove, though):

for ($i = 0; $i < 99; $i++) {
    for ($j = 0; $j < 10000; $j++) {
        $a = uniqid();
    }
    echo memory_get_usage(true), "\n";
}

Even if 990,000 uniqid()s (having 13 bytes each) will be allocated, on
my PHP 5.4.7 on Windows XP the output are 99 lines with 262144,
independent of the setting of zend.enable_gc.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#7555

On 11/14/2012 3:19 PM, Christoph Becker wrote:
> Jerry Stuckle wrote:
>> I thought of something else you may be misunderstanding.  This is NOT
>> the amount of memory allocated to PHP by the OS.  That is in multiples
>> of 4K blocks (for Intel architecture).  It is the amount actually
>> allocated for use by PHP.  Once that figure reaches the maximum memory
>> defined in the php.ini file, no more memory can be allocated by the script.
>
> I'm aware of the $real_usage parameter of memory_get_usage() and the
> different results reported according to the value of this parameter.
> And I assume, that the following invariant holds:
>
>      memory_get_usage(true) >= memory_get_usage(false)
>
>> Your interpretation would provide pretty worthless information as it
>> would not give a true account of memory being used.
>
> Isn't the true amount of memory being used by PHP (independent on how
> much is allocated by the OS) the relevant information for the given test?
>

Yes, and if a variable has been unset, it's storage is no longer being 
used by PHP.  It's in the pool to be cleaned up by the garbage 
collector, but that's different.

> However, reading
> <http://www.php.net/manual/en/features.gc.collecting-cycles.php> and
> <https://wiki.php.net/internals/zend_mm> still let's me assume, that
> zvals which refcount drops to zero are immediately freed (/not
> necessarily given back to the OS, though/).  The following test
> /supports/ my assumption (it's no prove, though):
>
> for ($i = 0; $i < 99; $i++) {
>      for ($j = 0; $j < 10000; $j++) {
>          $a = uniqid();
>      }
>      echo memory_get_usage(true), "\n";
> }
>
> Even if 990,000 uniqid()s (having 13 bytes each) will be allocated, on
> my PHP 5.4.7 on Windows XP the output are 99 lines with 262144,
> independent of the setting of zend.enable_gc.
>

That is correct.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7556

Jerry Stuckle wrote:
> Yes, and if a variable has been unset, it's storage is no longer being
> used by PHP.  It's in the pool to be cleaned up by the garbage
> collector, but that's different.

But what happens, if the garbage collector is disabled? [1]  Would none
of the allocated memory be freed?

[1] zend.enable_gc boolean
Enables or disables the circular reference collector.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#7566

On 11/14/2012 5:13 PM, Christoph Becker wrote:
> Jerry Stuckle wrote:
>> Yes, and if a variable has been unset, it's storage is no longer being
>> used by PHP.  It's in the pool to be cleaned up by the garbage
>> collector, but that's different.
>
> But what happens, if the garbage collector is disabled? [1]  Would none
> of the allocated memory be freed?
>
> [1] zend.enable_gc boolean
> Enables or disables the circular reference collector.
>

Why don't you try it and find out?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7578

Jerry Stuckle wrote:
> On 11/14/2012 5:13 PM, Christoph Becker wrote:
>> Jerry Stuckle wrote:
>>> Yes, and if a variable has been unset, it's storage is no longer being
>>> used by PHP.  It's in the pool to be cleaned up by the garbage
>>> collector, but that's different.
>>
>> But what happens, if the garbage collector is disabled? [1]  Would none
>> of the allocated memory be freed?
>>
>> [1] zend.enable_gc boolean
>> Enables or disables the circular reference collector.
>>
> 
> Why don't you try it and find out?

I did that already yesterday, posted the example code and the results,
and you've commented it with "That is correct."  So it was merely a
rethoric question.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#7535

Jerry Stuckle wrote:
>
> Personally, I don't think PHP would make a good daemon.  Among other
> things, you cannot manage memory yourself.  All you can do is unset()
> variables.  However, this does not release memory immediately.  It
> would wait for the garbage collector to run.
>
> When I'm writing daemons, I use C or C++.  They are much more
> appropriate, IMHO.

Thanks for your useful inputs gentlemen.

I sort of has given up hope for a daemon in PHP. I thought I can use its 
memory allocation functions directly, it turns out not. Even if I can, there 
is still garbage collector to contend with.

A helper mechanism has turned anti-mechanism in this case. :-( 

[toc] | [prev] | [next] | [standalone]

#7536

On 12/11/12 15:45, sl@exabyte wrote:
> Jerry Stuckle wrote:
>>
>> Personally, I don't think PHP would make a good daemon.  Among other
>> things, you cannot manage memory yourself.  All you can do is unset()
>> variables.  However, this does not release memory immediately.  It
>> would wait for the garbage collector to run.
>>
>> When I'm writing daemons, I use C or C++.  They are much more
>> appropriate, IMHO.
>
> Thanks for your useful inputs gentlemen.
>
> I sort of has given up hope for a daemon in PHP. I thought I can use its
> memory allocation functions directly, it turns out not. Even if I can, there
> is still garbage collector to contend with.
>
> A helper mechanism has turned anti-mechanism in this case. :-(
>
>
anything you can write in PHP you can write better and faster in C anyway..

I had a look at php for daemons and decided that the disadvantages 
outweighed the very few advantages., Its great for spitting out HTML, 
but I have seen issues with it with non re-entrant libraries even just 
running concurrent sessions from multiple web browsers.

Horses for courses.


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#7541

On 11.11.2012 18:18, sl@exabyte wrote:
> Anybody has experience of running php program as daemon ?
> 
> Would explicitly allocating and de-allocating all variables/memories be 
> effective for managing php daemon ?

PHP daemons are common pattern in some situations. E.g. how would you
implement AMQP listener without daemon?

But, due to the stateless nature of web, PHP is not made for daemonizing
:) Fortunately, there is solution, just keep in mind the following:

1. don't overuse this possibility - avoid it if you can
2. don't depend on PHP's memory management - shutdown your script
automatically from time to time just to be safe of memory leakage
3. auto start it immediately after shutdown - use supervisord

Basically, do this:

<?php

define('MAX_ITERATIONS', 10);

for ($iteration = 0; $iteration < MAX_ITERATIONS; $iteration++)
{
  // Do something nasty
  // ...

  sleep(10);
}

?>

[toc] | [prev] | [next] | [standalone]

#7545

On 11/13/2012 2:57 AM, Goran wrote:
> On 11.11.2012 18:18, sl@exabyte wrote:
>> Anybody has experience of running php program as daemon ?
>>
>> Would explicitly allocating and de-allocating all variables/memories be
>> effective for managing php daemon ?
>
> PHP daemons are common pattern in some situations. E.g. how would you
> implement AMQP listener without daemon?
>

I'd do it in C or C++.

> But, due to the stateless nature of web, PHP is not made for daemonizing
> :) Fortunately, there is solution, just keep in mind the following:
>

It has nothing to do with the stateless nature of the web.  PHP is good 
for non-web projects, also.  And C and other languages can be used for 
the web.

> 1. don't overuse this possibility - avoid it if you can
> 2. don't depend on PHP's memory management - shutdown your script
> automatically from time to time just to be safe of memory leakage
> 3. auto start it immediately after shutdown - use supervisord
>
> Basically, do this:
>
> <?php
>
> define('MAX_ITERATIONS', 10);
>
> for ($iteration = 0; $iteration < MAX_ITERATIONS; $iteration++)
> {
>    // Do something nasty
>    // ...
>
>    sleep(10);
> }
>
> ?>
>

What a kludge.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web