Garbage collection

[amygdala]

Hi,

I've read a few threads in this group recently, discussing garbage
collecting and unsetting variables and the likes. Concerning memory usage in
PHP: what is good practice, i.e. what should I be worried about, or what
kind of garbage collecting of my own should I consider?

Would it be good practice for instance to unset or set variables to NULL
immediately when I don't need them anymore. Also: do variables dissapear
from memory when out of scope? I would hope so.

Finally my gutfeeling tells me, that when a script stops, the memory that
was taken up by the script would clear instantly, but that doesn't always
seem the case considering what some people here have mentioned about it.
What's the real deal?

Thank you for any tips / advice on the matter.

[ZeldorBlat]

On Apr 26, 8:10 pm, "amygdala" <[e-mail]:

Hi,

I've read a few threads in this group recently, discussing garbage
collecting and unsetting variables and the likes. Concerning memory usage in
PHP: what is good practice, i.e. what should I be worried about, or what
kind of garbage collecting of my own should I consider?

Would it be good practice for instance to unset or set variables to NULL
immediately when I don't need them anymore. Also: do variables dissapear
from memory when out of scope? I would hope so.

Finally my gutfeeling tells me, that when a script stops, the memory that
was taken up by the script would clear instantly, but that doesn't always
seem the case considering what some people here have mentioned about it.
What's the real deal?

Thank you for any tips / advice on the matter.

This is what my boss likes to call "premature optimization." In
practice, you don't need to worry about any of this. If you run into
a specific problem, deal with it then. Un-setting all your variables
or setting them all to null when you're done will just clutter your
code. And yes, the memory used by a script should be released
automatically when the script is finished.

[=?ISO-8859-15?Q?Iv=E1n_S=E1nchez_Ortega?=]

amygdala wrote:

Finally my gutfeeling tells me, that when a script stops, the memory that
was taken up by the script would clear instantly, but that doesn't always
seem the case considering what some people here have mentioned about it.
What's the real deal?

Keep in mind things like persistent database connections - they'll use a
little bit of resources, but they're worth on the ling run. Session
variables also take some resources.

Also, the PHP interpreter is smart enough to cache the *code* of the
script - obviously, the heap and stack of every run is destroyed after the
run is complete. Expect the PHP engine to keep half-parsed code somewhere
in memory.

But, as I always say, PHP is a high-level language - the Zend guys worry
about memory allocation so you don't have to. You *do* have to worry about
the algorithms your app use: they make the real difference.

If you were programming in C, I'd tell you lots of memory management tips.
But now, I'll tell you to go to your library to read the Design Patterns
book (by the Gang of Four). Make a beautiful design, implement nice
algorithms, don't worry about the low-level stuff.

Cheers,
--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

http://acm.asoc.fi.upm.es/~mr/
Proudly running Debian Linux with 2.6.20-1-amd64 kernel, KDE3.5.3, and PHP
5.2.0-11 generating this signature.
Uptime: 02:39:11 up 3 days, 12:58, 2 users, load average: 0.23, 0.23, 0.22

[Jerry Stuckle]

Iván Sánchez Ortega wrote:

amygdala wrote:

>Finally my gutfeeling tells me, that when a script stops, the memory that
was taken up by the script would clear instantly, but that doesn't always
seem the case considering what some people here have mentioned about it.
What's the real deal?

Keep in mind things like persistent database connections - they'll use a
little bit of resources, but they're worth on the ling run. Session
variables also take some resources.

I disagree here. I have never found a use for persistent connections in
your average site.

Using persistent connections mean you need to allocate the maximum
connections you might ever need - and keep them allocated all the time.
This takes resources away from both the OS and the DBMS (and your
network if the DBMS is on a different server).

For instance - if you have a Halloween site with get real popular on
October 31st. You could need 100 connections for a short while. But
since you're using persistent connections, you'll need at least 100
connections allocated all the time.

OTOH, using non-persistent connections mean you're only using them when
you need them. On your average site this will probably average out to
well under 1 connection over a period of time. But on Halloween you can
get the 100 connections.

And connecting does take that long - most of the time it's completely
unnoticeable.

Google, which is constantly accessing their database thousands of times
per second would be a good case for persistent connection. But I don't
personally know anyone who's averaging even a dozen concurrent db
connection over a day, much less the entire year.

Also, the PHP interpreter is smart enough to cache the *code* of the
script - obviously, the heap and stack of every run is destroyed after the
run is complete. Expect the PHP engine to keep half-parsed code somewhere
in memory.

But, as I always say, PHP is a high-level language - the Zend guys worry
about memory allocation so you don't have to. You *do* have to worry about
the algorithms your app use: they make the real difference.

If you were programming in C, I'd tell you lots of memory management tips.
But now, I'll tell you to go to your library to read the Design Patterns
book (by the Gang of Four). Make a beautiful design, implement nice
algorithms, don't worry about the low-level stuff.

Cheers,

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

[gosha bine]

On 27.04.2007 02:10 amygdala wrote:

Hi,

I've read a few threads in this group recently, discussing garbage
collecting and unsetting variables and the likes. Concerning memory usage in
PHP: what is good practice, i.e. what should I be worried about, or what
kind of garbage collecting of my own should I consider?

In a scripting language you usually don't need to manage memory
explicitly, however there are some caveats in php MM you should know
about, for example, circular references.

>
Would it be good practice for instance to unset or set variables to NULL
immediately when I don't need them anymore. Also: do variables dissapear
from memory when out of scope? I would hope so.

Yes, they do, therefore your best option is to keep code structured, use
functions and avoid global variables.

>
Finally my gutfeeling tells me, that when a script stops, the memory that
was taken up by the script would clear instantly, but that doesn't always
seem the case considering what some people here have mentioned about it.
What's the real deal?

This should be this way, however there may be bugs in php core or
extensions that prevent memory from being freed.

>
Thank you for any tips / advice on the matter.

--
gosha bine

extended php parser ~ http://code.google.com/p/pihipi
blok ~ http://www.tagarga.com/blok

[Toby A Inkster]

amygdala wrote:

Finally my gutfeeling tells me, that when a script stops, the memory that
was taken up by the script would clear instantly, but that doesn't always
seem the case considering what some people here have mentioned about it.
What's the real deal?

It doesn't clear *instantly* -- the PHP interpreter is smarter than that,
waiting for a bit of system idle time and clearing a bunch of memory at
once rather than simply clearing things as soon as they're not needed.

But, from your own point of view, you don't need to worry about PHP's
garbage collection algorithm -- that's the whole point of using a high
level language like PHP -- not having to worry about the nitty gritty
things like this!

--
Toby A Inkster BSc (Hons) ARCS
http://tobyinkster.co.uk/
Geek of ~ HTML/SQL/Perl/PHP/Python*/Apache/Linux

* = I'm getting there!

[amygdala]

"amygdala" <no*****@noreply.comschreef in bericht
news:46***********************@news.kpnplanet.nl.. .

Hi,

I've read a few threads in this group recently, discussing garbage
collecting and unsetting variables and the likes. Concerning memory usage
in PHP: what is good practice, i.e. what should I be worried about, or
what kind of garbage collecting of my own should I consider?

Would it be good practice for instance to unset or set variables to NULL
immediately when I don't need them anymore. Also: do variables dissapear
from memory when out of scope? I would hope so.

Finally my gutfeeling tells me, that when a script stops, the memory that
was taken up by the script would clear instantly, but that doesn't always
seem the case considering what some people here have mentioned about it.
What's the real deal?

Thank you for any tips / advice on the matter.

Thanks for the response people. That's reassuring.

[Chung Leong]

On Apr 27, 2:48 am, Iván Sánchez Ortega <ivansanchez-...@rroba-
escomposlinux.-.punto.-.orgwrote:

Session variables also take some resources.

Session variables--by default at least--are stored in files. They
don't take up memory.

Also, the PHP interpreter is smart enough to cache the *code* of the
script - obviously, the heap and stack of every run is destroyed after the
run is complete. Expect the PHP engine to keep half-parsed code somewhere
in memory.

Nope, the PHP interpreter is pretty dumb by default. Script files are
always reparsed. You have to pay for the smart, in the form of the
Zend Accelerator (or whatever it's called nowadays).

[Chung Leong]

On Apr 27, 5:02 am, Jerry Stuckle <[e-mail]:

Using persistent connections mean you need to allocate the maximum
connections you might ever need - and keep them allocated all the time.
This takes resources away from both the OS and the DBMS (and your
network if the DBMS is on a different server).

That's not entirely true. In a Apache + PHP system, there would be one
persistent connections (of one type) per child process. The number of
idle processes does not equal the maximum number of connections.
Apache will spawn more child processes as necessary. And it will shut
down extra spares if there are too many. Persistent connections owned
by these unwanted children would then be closed.

Persistent connections are problematic when the number of database
connections are limited. When the number of Apache processes exceeds
this number, obviously some of them wouldn't be able to get a
connection. And those that do own connections might not even be using
them--they could be handling file downloads for instance.

I think it's conceivable that a server could run out of database
connections while there is zero database activity:

1. A visitor goes to page to download a file
2. The PHP script open a persistent connection in order to log the
download in the database
3. The browser reuses the same HTTP connection (keep-alive) for the
download
4. For the next three hours, the child process handling the request
just sits on the DB connection

Repeat a hundred times or two and all connections will be exhausted.
Not an efficient scheme at all.

[Jerry Stuckle]

Chung Leong wrote:

On Apr 27, 5:02 am, Jerry Stuckle <[e-mail]:

>Using persistent connections mean you need to allocate the maximum
connections you might ever need - and keep them allocated all the time.
This takes resources away from both the OS and the DBMS (and your
network if the DBMS is on a different server).

That's not entirely true. In a Apache + PHP system, there would be one
persistent connections (of one type) per child process. The number of
idle processes does not equal the maximum number of connections.
Apache will spawn more child processes as necessary. And it will shut
down extra spares if there are too many. Persistent connections owned
by these unwanted children would then be closed.

Persistent connections are problematic when the number of database
connections are limited. When the number of Apache processes exceeds
this number, obviously some of them wouldn't be able to get a
connection. And those that do own connections might not even be using
them--they could be handling file downloads for instance.

I think it's conceivable that a server could run out of database
connections while there is zero database activity:

1. A visitor goes to page to download a file
2. The PHP script open a persistent connection in order to log the
download in the database
3. The browser reuses the same HTTP connection (keep-alive) for the
download
4. For the next three hours, the child process handling the request
just sits on the DB connection

Repeat a hundred times or two and all connections will be exhausted.
Not an efficient scheme at all.

Chung,

Ah, but the number of persistent connections is a MySQL parameter, and
is not limited to the Apache process. They may be C/C++ connections,
for instance. Or CLI, PEAR, or anything else which can connect to MySQL.

It has nothing to do with the number of Apache processes running - MySQL
will keep the connections open even if Apache itself shuts down.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================