optimization

Logging Apache response times

Dynamic Website Compressor

I haven’t tested it enough myself yet, but it looks very much like Google’s mod_pagespeed. The difference mostly being with Google approaching the problem via the Apache module, which should be faster, but less portable; and Dynamic WebSite Composer doing all its magic in your regular PHP. The only way I can think for this to work is via output buffering, so if you are using that in your application, test thoroughly.

How To Survive a Ground-Up Rewrite Without Losing Your Sanity

Developers tend to spectacularly underestimate the effort involved in such a rewrite (more on that below), and spectacularly overestimate the value generated (more on that below, as well).

Configuring the Apache MPM on Fedora

If you take nothing else away from this article, let it be that you should tailor your MPM’s MaxClients setting so that your web server won’t try to allocate more resources than you have available. Better that a visitor wait a moment for a connection than that the server should dip into swap for more memory and bring the entire virtual machine to a crawl.

SPL – Standard PHP Library

I’ve been looking at SPL for some time now. On one hand, it’s a new addition to PHP core (since version 5.3), so I know how to work without it. On the other hand, it provides standardized solutions for common problems, and that should be enough reason to start using it. However, today I came across an interesting article that provides even more reason to use SPL.

In this post I want to investigate the memory usage of PHP arrays (and values in general) using the following script as an example, which creates 100000 unique integer array elements and measures the resulting memory usage:
$startMemory = memory_get_usage();
$array = range(1, 100000);
echo memory_get_usage() - $startMemory, ' bytes';
How much would you expect it to be? Simple, one integer is 8 bytes (on a 64 bit unix machine and using the long type) and you got 100000 integers, so you obviously will need 800000 bytes. That’s something like 0.76 MBs.

Now try and run the above code. You can do it online if you want. This gives me 14649024 bytes. Yes, you heard right, that’s 13.97 MB – eightteen times more than we estimated.

[…]

But if you do want to save memory you could consider using an SplFixedArray for large, static arrays.

Have a look a this modified script:
$startMemory = memory_get_usage();
$array = new SplFixedArray(100000);
for ($i = 0; $i < 100000; ++$i) {
    $array[$i] = $i;
}
echo memory_get_usage() - $startMemory, ' bytes';
It basically does the same thing, but if you run it, you’ll notice that it uses “only” 5600640 bytes. That’s 56 bytes per element and thus much less than the 144 bytes per element a normal array uses. This is because a fixed array doesn’t need the bucket structure: So it only requires one zval (48 bytes) and one pointer (8 bytes) for each element, giving us the observed 56 bytes.

For years I’ve been suffering from PHP’s memory hunger. I’ve had to optimize the code around smaller memory footprints, unset variables, and do all sorts of other messy things, that I normally wouldn’t have in a high-level programming language like PHP. With SPL, it seems, there is more help on the horizon.