On the Internet Super Hero blog, they take a quick look at what's new in the MySQL native driver version that will be included in the upcoming PHP version, PHP 5.3.

PDO_MYSQLND is in the PHP CVS repository at php.net: PDO_MYSQL has been patched (PHP 5.3, PHP 6.0). Try out PDO_MYSQL with the MySQL native driver for PHP (mysqlnd). Its has new features.

They do a short recap of what the native driver libraries are all about and some of the advantages to using them. They look at some of the "memory tricks" supported by the driver and a look at the prepared statement and procedure support.

In this quick post to the ApacheLounge forum, Steffen shares some stats running PHP in two different methods of running PHP on Apache - mod_php and fastcgi.

With PHP as module after some time the memory usage of Apache is growing and growing up to ~800M.
With mod_fcgid is stays on a steady ~100M
PHP configuration: only with the extension php_mysql.dll and eaccelerator.dll

A graph of the statistics is also provided.

Posted to his blog, Dave Marshall has a tip that uses declare and a trick or two to check out the memory usage of your scripts.

As far as I know, there isn't any memory footprint profiling in Xdebug, I think there was at some point but they removed it because it was a little flaky. I like to monitor the memory usage within my scripts, and I've found this simple snippet can help.

The script defines a log_memory function that pushes the memory and time information into a session value. The register_tick_function method is used to add log_memory to the handler and its called over and over from inside his for loop.

Matthew Turland notes that the second part of his "IRC Bots in PHP" series of articles has been posted to the C7Y community site (from php|architect).

The precursor to this article introduced some background and an overview of the design for the Phergie project as an example of the concepts involved in a PHP IRC bot implementation. This article will go further into the topic of plugins including descriptions of those that are commonly needed to make a bot fully functional as well as the commonly needed core features to support plugin development.

In part one he set up some of the foundation code and explained some of the thought behind the structure of the bot. In this part he gets more into the heart of the bot, showing how to define functions for common IRC actions (join/part/ping/etc) and how he made a plugin system to handle custom actions. He also mentions topics like memory usage, data storage methods and some of the "niceties" he included.

The PHP-GTK Community Site has posted about an issue that's been found with PHP-GTK on a Windows Vista machine that can cause problems with how the OS handles memory (by Wim Stockman).

My work station is WinXp system and my friend where I had to create it for has the new Vista and somewhere over 9000 pictures to be managed. On my system everything worked fine, but on my friends system i always got the error can not open file.

Further testing revealed that it was the OS at fault - Vista wasn't handling the memory usage for the application correctly. When it was run directly from the file explorer (versus in the PHP-GTK console) though, it worked just fine.

In a recent post to his blog, Brian Moon talks about the experience he's had with using PHP on Apache 2 with a threaded MPM at Dealnews.com.

Well, first, what is an MPM? It stands for Multi-Processing Module. [...] The most commonly used threaded MPM is the Worker MPM. In this MPM, you have several processes that run multiple threads within it. This is the one I will be talking about.

He goes on to describe the "huge memory savings" that using the module got them - using the worker process to increase the child capacity of the Apache instance. He recommends keeping it simple when compiling a server to work with the worker functionality and mentions how it can also help with serving static pages right along side the dynamic ones (without a second server!).

Check out the post for a few more tips.

Christopher Jones talks today on his blog about a bug he's just corrected and integrated into the release of the Oracle Instant Client that lets PHP correctly take advantage of the temporary LOBS functionality.

When PHP is done with the temporary LOB, it needs to tell Oracle to destroy it. If this isn't done, then the temporary LOB will hang around using DB space until the connection is closed. I just merged a fix worked on by Krishna Mohan and myself for bug 43497.

Example code is included showing two instances of its use - a normal use that frees the memory correctly and the other showing how to create the temporary lob to hold the data as needed.

Paul Jones presents a problem he was having in a new post to his blog - the issue was with memory leaks in objects in a PHP5 application he was working on.

One of the nice things about using a scripting language is that it automates garbage collection for you. You don't have to worry about releasing memory when you're done with your variables. [...] But there is at least one circumstance in which PHP will not free memory for you when you call unset(). Cf. http://bugs.php.net/bug.php?id=33595.

The problem is that, when trying to unset the parent object in a parent/child relationship, the memory space for the parent reference in the child isn't removed. The problem, left unchecked can cause a script to go over the memory limit pretty easily (especially with larger objects).

He suggests two solutions - one that the user can control (calling a destructor before unsetting the object) or a PHP internals method that involves fixing issues with the reference counts created with the objects.

On his blog today, Alex Netkachov has posted a suggestion of how to combat a common issue facing PHP scripts - their memory usage.

PHP has a build-in garbage collector so you do not need to track the links on the objects, allocate memory for objects and delete them when they are not longer necessary. Things seem so perfect that developers do not even know that their scripts allocate a lot of memory until their server stops processing requests because of the out of memory error.

His example is the processing of a parent/child relationship tree. If not managed correctly, the variables being used could get out of hand quite quickly. Alex recommends the use of a "destructor" at the end of each iteration to help destroy variables and values no longer needed.

A new note on the Internet Super Hero blog talks about a new improvement to the mysqlnd driver support a memory dump option for mysqli_debug.

Andrey has implemented a little mysqlnd only addition to mysqli_debug(): 'm' - dump memory information. It works like the other options described in PHP: Debugging ext/mysqli and mysqlnd with the only difference that it is only available with mysqlnd.

A comparison of the "before option 'm'" and "after option 'm'" is also included.