PHP - 4

For our database connections we PDO at work and we've extended the class with PHP to offer some other convenience functionality and wrappers. One of the things I wanted to do recently is allow the constructor of the PDO class to fail-over to our backup database connection pool in the event the primary was not available. The idea was to do something along the lines of:

<?php



class DB extends PDO {

 public function __construct($dsn, $login, $pass, $backup_dsn) {

        try {

           parent::__construct($dsn, $login, $pass);

        } catch (Exception $e) {

            parent::__construct($backup_dsn, $login, $pass);

        }

 }

}



?>

Essentially the code would call the PDO's own constructor, if it would fail, an exception would be raised, which would then be caught by the exception handler that will attempt to connect to the backup database connection pool. Unfortunately this simple solution does not work, the reason being, is that when PDO's constructor fails to connect, it destroys the object. Which means any attempts to use or access the object fail, even $this is equal to NULL, effectively making the 2nd construct call pointless.

While this behaviour makes sense on most cases, in some cases such as a fallback scenario illustrated above this is an undesired behaviour. To address this limitation I've written a small patch (http://ilia.ws/patch/pdo.txt) which introduces a PDO:: ATTR_KEEP_CLASS_CONN_FAILURE configuration option that can be passed to PDO's constructor, telling it to keep the object alive after a failed attempt to connect to the database, allowing re-connection to be attempted. With this patch in place, the above code can be implemented as per example below.

<?php



class DB extends PDO {

 public function __construct($dsn, $login, $pass, $backup_dsn) {

        try {

           parent::__construct($dsn, $login, $pass, array(PDO:: ATTR_KEEP_CLASS_CONN_FAILURE => 1));

        } catch (Exception $e) {

            parent::__construct($backup_dsn, $login, $pass);

        }

 }

}



?>

At Confoo I had an interesting conversation with Guilherme Blanco regarding the fact that in Doctrine 2 they had a performance issue due to usage of array_key_exists() and how it was significantly slower than isset(). His anecdotal example was that doing isset() took 0.5 seconds, while array_key_exists() for the same operation took 5 seconds!

That seemed wrong, given that array_key_exists() simply does a hash table look-up, to determine if the array key exists and the only speed difference would be due to the fact that isset() is a language construct and does not have the overhead of function & parameter processing. So, I've decided to do a quick benchmark using a 5,000 element array.

<?php



$arr = array();

$fp = fopen("/usr/share/dict/words", "r");

while ($i < 5000 && ($w = fgets($fp))) {

    $arr[trim($w)] = ++$i;

}



$s = microtime(1);

for ($i = 0; $i < 100000; $i++) {

    isset($arr['abracadabra']);

}

$e = microtime(1);



echo "Isset: ".($e - $s)."\n";



$s = microtime(1);

for ($i = 0; $i < 100000; $i++) {

    array_key_exists('abracadabra', $arr);

}

$e = microtime(1);



echo "array_key_exists: ".($e - $s)."\n";



?>

The above benchmark executed on PHP 5.4 shows that while isset() is 2.5 times faster taking a mere 0.0219 seconds vs 0.0549 seconds taken by array_key_exists(), both operations are extremely quick and take a fraction of a second even when doing 100k operations. Any "optimization" between the calls is purely within the super-micro-micro optimization realm and is not going to make any application measurably faster.

The bottom line is that if your application does not need to distinguish between an array key that does not exist and one whose value happens to be NULL you should use isset() because it happens to be a little faster. However, if a NULL array key value and a non-existant array key are something you need to differentiate between, use array_key_exists() and you don't need to worry about the performance, the function is extremely fast, even in the case of Doctrine 2 that apparently may do as many as 50,000 calls to the function per-request in some cases.

While profiling our application I came across a a rather strange memory usage by the ob_start() function. We do use ob_start() quite a bit to defer output of data, which is a common thing in many applications. What was unusual is that 16 calls to ob_start() up chewing through almost 700kb of memory, given that the data being buffered rarely exceeds 1-2kb, this was quite unusual.

I started looking at the C code of the ob_start() function and found this interesting bit of code inside php_start_ob_buffer()
initial_size = 40*1024;
block_size = 10*1024;

Which directs PHP to pre-allocate 40kb of data for each ob_start() call and when this proves to be insufficient, increase by 10kb each time. Ouch!

PHP does allow you to say how much memory ob_start() can use, via 2nd parameter to the function. However, if you exceed that size, PHP will promptly flush the captured data to screen, which means that unless you are really good at predicting your buffer sizes or vastly overestimate, there is a risk that the data will be dumped to screen by PHP if you use this option.

Since I am not really good at guessing, I've decided to make a small, backwards compatible tweak to PHP's code that allow specification of custom buffer sizes, but allow the buffer size to be increased if the initial buffer size proves to be insufficient, ensuring that the data can be safely buffered. This functionality is implemented through a change (see patch below) to the 1st parameter of the ob_start() function, which normally is used to provide the callback function. With the patch in place the parameter, can be a number, which defines the desired buffer size. With the patch, ob_start(1024) means that the 1kb buffer should be used and when it is exceed keep allocating 1kb at a time to allow for additional data to be stored. This solution does mean you cannot use custom, resizable buffer sizes with a callback function, however it does provider a backwards (PHP API wise) compatible way of implementing the functionality in PHP 5.2 and 5.3.

<?php



     ob_start(null, 1024);

     echo str_repeat("a", 1500);

     var_dump(strlen(ob_get_clean()));



?>

<?php



     ob_start(1024);

     echo str_repeat("a", 1500);

     var_dump(strlen(ob_get_clean()));



?>