FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » php daemon
Show: Today's Messages :: Unread Messages :: Show Polls :: Message Navigator
| Subscribe to topic | Bookmark topic 
Switch to threaded view of this topic Create a new topic Submit Reply
php daemon [message #179589] Sun, 11 November 2012 12:18 Go to next message
SL is currently offline  SL
Messages: 20
Registered: February 2012
Karma: 0
Junior Member
add to buddy list
ignore all messages by this user
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.
Re: php daemon [message #179591 is a reply to message #179589] Sun, 11 November 2012 14:04 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
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(at)attglobal(dot)net
==================
Re: php daemon [message #179592 is a reply to message #179591] Sun, 11 November 2012 15:05 Go to previous messageGo to next message
Christoph Becker is currently offline  Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
Member
add to buddy list
ignore all messages by this user
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
Re: php daemon [message #179593 is a reply to message #179592] Sun, 11 November 2012 15:35 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
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(at)attglobal(dot)net
==================
Re: php daemon [message #179594 is a reply to message #179593] Sun, 11 November 2012 16:22 Go to previous messageGo to next message
Christoph Becker is currently offline  Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
Member
add to buddy list
ignore all messages by this user
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
Re: php daemon [message #179595 is a reply to message #179594] Sun, 11 November 2012 16:36 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
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(at)attglobal(dot)net
==================
Re: php daemon [message #179596 is a reply to message #179595] Sun, 11 November 2012 17:17 Go to previous messageGo to next message
Christoph Becker is currently offline  Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
Member
add to buddy list
ignore all messages by this user
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
Re: php daemon [message #179597 is a reply to message #179596] Sun, 11 November 2012 18:11 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
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(at)attglobal(dot)net
==================
Re: php daemon [message #179600 is a reply to message #179597] Mon, 12 November 2012 08:35 Go to previous messageGo to next message
Christoph Becker is currently offline  Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
Member
add to buddy list
ignore all messages by this user
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
Re: php daemon [message #179602 is a reply to message #179600] Mon, 12 November 2012 08:38 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
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(at)attglobal(dot)net
==================
Re: php daemon [message #179604 is a reply to message #179591] Mon, 12 November 2012 10:45 Go to previous messageGo to next message
SL is currently offline  SL
Messages: 20
Registered: February 2012
Karma: 0
Junior Member
add to buddy list
ignore all messages by this user
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. :-(
Re: php daemon [message #179605 is a reply to message #179604] Mon, 12 November 2012 11:08 Go to previous messageGo to next message
The Natural Philosoph is currently offline  The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
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.
Re: php daemon [message #179610 is a reply to message #179589] Tue, 13 November 2012 02:57 Go to previous messageGo to next message
Goran is currently offline  Goran
Messages: 38
Registered: January 2011
Karma: 0
Member
add to buddy list
ignore all messages by this user
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);
}

?>
Re: php daemon [message #179613 is a reply to message #179600] Tue, 13 November 2012 07:44 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
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(at)attglobal(dot)net
==================
Re: php daemon [message #179614 is a reply to message #179610] Tue, 13 November 2012 07:47 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
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(at)attglobal(dot)net
==================
Re: php daemon [message #179616 is a reply to message #179614] Tue, 13 November 2012 08:54 Go to previous messageGo to next message
Goran is currently offline  Goran
Messages: 38
Registered: January 2011
Karma: 0
Member
add to buddy list
ignore all messages by this user
On 13.11.2012 13:47, Jerry Stuckle wrote:
> I'd do it in C or C++.

Ok, let's all hire the C daemon guy, explain this to human resources
department...

> What a kludge.

Wll, life is a kludge too
Re: php daemon [message #179617 is a reply to message #179616] Tue, 13 November 2012 09:13 Go to previous messageGo to next message
The Natural Philosoph is currently offline  The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
On 13/11/12 13:54, Goran wrote:
> On 13.11.2012 13:47, Jerry Stuckle wrote:
>> I'd do it in C or C++.
>
> Ok, let's all hire the C daemon guy, explain this to human resources
> department...
>

Oh FFS its hardly rocket science to write a basic daemon with all the
crib code out there.


>> What a kludge.
>
> Wll, life is a kludge too
>


--
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.
Re: php daemon [message #179618 is a reply to message #179616] Tue, 13 November 2012 12:23 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
On 11/13/2012 8:54 AM, Goran wrote:
> On 13.11.2012 13:47, Jerry Stuckle wrote:
>> I'd do it in C or C++.
>
> Ok, let's all hire the C daemon guy, explain this to human resources
> department...
>

Yes, let's do it right. You could also contract it out.


>> What a kludge.
>
> Wll, life is a kludge too
>

Sorry to hear your's is.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
Re: php daemon [message #179621 is a reply to message #179618] Wed, 14 November 2012 02:43 Go to previous messageGo to next message
Goran is currently offline  Goran
Messages: 38
Registered: January 2011
Karma: 0
Member
add to buddy list
ignore all messages by this user
On 13.11.2012 18:23, Jerry Stuckle wrote:
>> Ok, let's all hire the C daemon guy, explain this to human resources
>> department...
> Yes, let's do it right. You could also contract it out.

There is nothing wrong with PHP daemons. As I mentioned, example I wrote
is common pattern in PHP world so it is proven solution.
But yes, if you are lazy enough you could hire C programmer.

> Sorry to hear your's is.

Oh, it's personal now?
Re: php daemon [message #179622 is a reply to message #179621] Wed, 14 November 2012 05:51 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
On 11/14/2012 2:43 AM, Goran wrote:
> On 13.11.2012 18:23, Jerry Stuckle wrote:
>>> Ok, let's all hire the C daemon guy, explain this to human resources
>>> department...
>> Yes, let's do it right. You could also contract it out.
>
> There is nothing wrong with PHP daemons. As I mentioned, example I wrote
> is common pattern in PHP world so it is proven solution.
> But yes, if you are lazy enough you could hire C programmer.
>

Yes, it is a common pattern for people who don't know better.
Knowledgeable programmers understand PHP is not a good language to write
daemons. They use an appropriate language which doesn't have to resort
to such kludges.

>> Sorry to hear your's is.
>
> Oh, it's personal now?
>

You're the one who claimed life's a kludge, so yours must be. Mine isn't.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
Re: php daemon [message #179623 is a reply to message #179613] Wed, 14 November 2012 15:19 Go to previous messageGo to next message
Christoph Becker is currently offline  Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
Member
add to buddy list
ignore all messages by this user
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
Re: php daemon [message #179624 is a reply to message #179623] Wed, 14 November 2012 16:33 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
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(at)attglobal(dot)net
==================
Re: php daemon [message #179625 is a reply to message #179624] Wed, 14 November 2012 17:13 Go to previous messageGo to next message
Christoph Becker is currently offline  Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
Member
add to buddy list
ignore all messages by this user
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
Re: php daemon [message #179635 is a reply to message #179625] Thu, 15 November 2012 07:41 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
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(at)attglobal(dot)net
==================
Re: php daemon [message #179638 is a reply to message #179622] Thu, 15 November 2012 08:08 Go to previous messageGo to next message
Goran is currently offline  Goran
Messages: 38
Registered: January 2011
Karma: 0
Member
add to buddy list
ignore all messages by this user
On 14.11.2012 11:51, Jerry Stuckle wrote:
> You're the one who claimed life's a kludge, so yours must be. Mine isn't.

As I can see, you tend to overcomplicate things, that's why I believe
your life is a mess.

> Yes, it is a common pattern for people who don't know better.

Maybe it's time for you to start defining what's wrong with my example
(after so much bs talk). Define kludge.
Re: php daemon [message #179640 is a reply to message #179638] Thu, 15 November 2012 08:46 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
On 11/15/2012 8:08 AM, Goran wrote:
> On 14.11.2012 11:51, Jerry Stuckle wrote:
>> You're the one who claimed life's a kludge, so yours must be. Mine isn't.
>
> As I can see, you tend to overcomplicate things, that's why I believe
> your life is a mess.
>

Nope, you're the one who had to put together a kludge instead of using a
more appropriate language.

>> Yes, it is a common pattern for people who don't know better.
>
> Maybe it's time for you to start defining what's wrong with my example
> (after so much bs talk). Define kludge.
>

You have to keep stopping and starting it, for one thing. And in your
loop you need to sleep() for a while.

And you confuse the "stateless nature of the web" with daemons - they
have nothing to do with each other.

Or maybe you don't understand what a daemon is, or how a *real* daemon
works.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
Re: php daemon [message #179642 is a reply to message #179640] Thu, 15 November 2012 10:09 Go to previous messageGo to next message
Goran is currently offline  Goran
Messages: 38
Registered: January 2011
Karma: 0
Member
add to buddy list
ignore all messages by this user
On 15.11.2012 14:46, Jerry Stuckle wrote:
> On 11/15/2012 8:08 AM, Goran wrote:
>> On 14.11.2012 11:51, Jerry Stuckle wrote:
>>> You're the one who claimed life's a kludge, so yours must be. Mine
>>> isn't.
>>
>> As I can see, you tend to overcomplicate things, that's why I believe
>> your life is a mess.
>>
>
> Nope, you're the one who had to put together a kludge instead of using a
> more appropriate language.

I guess you are the kind of person which prefer to buy a car instead of
paying for single taxi drive.

>>> Yes, it is a common pattern for people who don't know better.
>>
>> Maybe it's time for you to start defining what's wrong with my example
>> (after so much bs talk). Define kludge.
>>
>
> You have to keep stopping and starting it, for one thing. And in your
> loop you need to sleep() for a while.

Every daemon needs loop, sleep is completely optional in every language
(it's just an example). Whats wrong with restarting? It's not your job,
it's supervisord's job. Even regular daemons need autorestarting for
failover sometimes.

> And you confuse the "stateless nature of the web" with daemons - they
> have nothing to do with each other.

You took it out of context, how appropriate...

PHP is scripting language primarily made for web - not designed to deal
with long running applications. Therefor, it's memory management is not
so precise - it's optimized for performance, not for memory usage.
Therefore, it's ideal for "stateless nature of the web", because there
is no need to carry state among http requests.

Although, it's suboptimal for daemons, with a little help of supervisord
it can be efficient enough.

> Or maybe you don't understand what a daemon is, or how a *real* daemon
> works.

You know what? My dad eat daemons for breakfast!
Re: php daemon [message #179647 is a reply to message #179635] Thu, 15 November 2012 10:55 Go to previous messageGo to next message
Christoph Becker is currently offline  Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
Member
add to buddy list
ignore all messages by this user
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
Re: php daemon [message #179649 is a reply to message #179640] Thu, 15 November 2012 11:20 Go to previous messageGo to next message
Tim Streater is currently offline  Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
In article <k82rn7$fgl$1(at)dont-email(dot)me>,
Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:

> On 11/15/2012 8:08 AM, Goran wrote:
>> On 14.11.2012 11:51, Jerry Stuckle wrote:
>>> You're the one who claimed life's a kludge, so yours must be. Mine isn't.
>>
>> As I can see, you tend to overcomplicate things, that's why I believe
>> your life is a mess.
>>
>
> Nope, you're the one who had to put together a kludge instead of using a
> more appropriate language.
>
>>> Yes, it is a common pattern for people who don't know better.
>>
>> Maybe it's time for you to start defining what's wrong with my example
>> (after so much bs talk). Define kludge.
>>
>
> You have to keep stopping and starting it, for one thing. And in your
> loop you need to sleep() for a while.

I haven't looked into whether PHP offers any such facilities, but what
should really be happening is:

wait ();

where the wait is exited if an event occurs. It would require the
capability to declare something to be an event and to queue a work item
when the event occurs, etc etc.

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
Re: php daemon [message #179650 is a reply to message #179642] Thu, 15 November 2012 11:25 Go to previous message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
On 11/15/2012 10:09 AM, Goran wrote:
> On 15.11.2012 14:46, Jerry Stuckle wrote:
>> On 11/15/2012 8:08 AM, Goran wrote:
>>> On 14.11.2012 11:51, Jerry Stuckle wrote:
>>>> You're the one who claimed life's a kludge, so yours must be. Mine
>>>> isn't.
>>>
>>> As I can see, you tend to overcomplicate things, that's why I believe
>>> your life is a mess.
>>>
>>
>> Nope, you're the one who had to put together a kludge instead of using a
>> more appropriate language.
>
> I guess you are the kind of person which prefer to buy a car instead of
> paying for single taxi drive.
>

Absolutely nothing to do with the question. I prefer to do it *right*.

>>>> Yes, it is a common pattern for people who don't know better.
>>>
>>> Maybe it's time for you to start defining what's wrong with my example
>>> (after so much bs talk). Define kludge.
>>>
>>
>> You have to keep stopping and starting it, for one thing. And in your
>> loop you need to sleep() for a while.
>
> Every daemon needs loop, sleep is completely optional in every language
> (it's just an example). Whats wrong with restarting? It's not your job,
> it's supervisord's job. Even regular daemons need autorestarting for
> failover sometimes.
>

Yes, but good daemons don't need to stop and restart. They also don't
use sleep().

As for restarting - extra overhead on the processor, for one thing. But
mainly the daemon loses any existing values, and is not available during
the restart procedure.

I can imagine how far an ftp server daemon would go if you had to log on
after every ten blocks were uploaded!

>> And you confuse the "stateless nature of the web" with daemons - they
>> have nothing to do with each other.
>
> You took it out of context, how appropriate...
>

Nope. You're the one who mentioned them together.

> PHP is scripting language primarily made for web - not designed to deal
> with long running applications. Therefor, it's memory management is not
> so precise - it's optimized for performance, not for memory usage.
> Therefore, it's ideal for "stateless nature of the web", because there
> is no need to carry state among http requests.
>

PHP is written as a web language, but it's also good for scripting
files. And no, it is not "optimized for performance". It is "optimized
for ease of coding". PHP performance is actually pretty bad when
compared to other languages like C. But while you *can* use C for web
projects, it is not a good choice, IMHO.

And yes, there is a need for carrying state amongst http requests.
That's what $_SESSION is all about.

> Although, it's suboptimal for daemons, with a little help of supervisord
> it can be efficient enough.
>

It's crap for daemons. It was never meant to be used for them. But
then there are always people why try to use a hammer when a screwdriver
is more appropriate.

>> Or maybe you don't understand what a daemon is, or how a *real* daemon
>> works.
>
> You know what? My dad eat daemons for breakfast!
>

I can believe that!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
Quick Reply
Formatting Tools:   
  Switch to threaded view of this topic Create a new topic
Previous Topic: Benefits of the 3-Tier Architecture
Next Topic: Bad database design can cause unnecessary coding
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu Oct 19 14:29:25 EDT 2017

Total time taken to generate the page: 0.01040 seconds