Basically, there are function which expect strings and the implicit _toString() call on an object will leak memory. Testcase:

< ?php
    class Foo {
        function __toString() {
            return 'foo';
        }
    }
    for ($i = 0; $i < 1e5; $i++) {

        $o = new Foo;

        # leaks
        md5($o);
        # does not leak
        #md5($o->__toString());

        # does not leak either way
        # strstr($o, 'f');
        #strstr($o->__toString(), 'f');

        if ($i % 1e3 == 0) {
            printf("%u: %1.2f KB\n",
                $i, memory_get_usage(true) / 1024);
        }
    }

We currently haven’t the templates connected to the CMS yet, but the raw time is currently between 700 and 900ms. Maybe it can be justified because the layout isn’t Web 1.0 style (i.e. many round corners, shadows, etc.).

What puzzled me was the “loading time of JavaScript was around 300ms”, see this picture:

That’s quite a long time. It may is not that good visible from the chart, but nearly everything following the JavaScript is hold until it is read, which delays the complete loading of the rest of the page.

Since behind the scenes the actual request is in reality using Minify, it’s not just plain serving (but for this scenario the JavaScript has already been cached).

So I took a look just at the JavaScript loading, see this:

What’s that? Roughly 30ms vs 300ms?

The only realistic guess I’ve at the moment is: parsing the JavaScript.

This single request loads the following libraries:

• behaviour
• prototype
• scriptaculous (+effects)
• yui: yahoo-dom-event
• yui: container_core
• yui: menu.js
• our own small JavaScript parts

Maybe I’m too optimistic but it hit me a bit that JavaScript parsing still does take so long. Given that the JavaScript is cached (ideally) things such a huge problem, but still. It was frustrating that I could trim down the >1s request to ~700ms but not further and for most of the part just because it takes as long as it needs it.

My selector looked like .menu and unfortunately it also did match div class="menu-selector" in my code. This is because a dash also counts as word boundary when using Javascript \b pattern.

I modified the class matching regular expression do the following

'(^|\s)' + className + '($|\s)'

and this did work very well for me.

I’m currently trying to contact Simon Willison about his opinion whether this change is a good idea or not, I’ll update this post once I’ve received feedback.

Basic usage:

php mysqltail.php /var/log/mysql.log userToFilter [orOtherUser]

It can also be used to pipe an existing logfile:

cat mysql.log | php mysqltail.php - userToFilter

Download: http://markus.fischer.name/lab/php/mysqltail.php.txt

You need a proper server environment where your application can run, the components need to have the required version, etc. Setting up web server is not hard but tuning all required parameters takes time. And usually in a team of developers someone is responsible for the configuration management; and there’s a reason for that.

Because of the resources it takes to set up such an environment, the common sense when developing applications is usually that there’s one server for all developers and that there are one or two fixed checkouts of a project. That’s a bit against the philosophy on how versioning systems are designed to work. Each and every developer should have its own checkout. But with a complex environment it’s not always feasable to have this process. When it takes so much resources to have the central development server fine tuned you can bet it takes even more for local development on the developers computer.

My goal was that we have flexibility:

• have a place were we check out a complte project and multiple (!) developer can work on one checkout (traditional)
• have a place for each developer on the development server where he can check out as many custom web projects as he wants
• make it next to zero work to create new apache configurations for new projects (VirtualHosts, etc.)

I solved this with a small PHP class and some shell scripting, which basically can generate working apache VirtualHosts configuration on the fly. For this we need to know a few things first:

• the path where the apache configuration templates are stored
• the path to the common checked out projects
• the base directory for user specific checked out projects
• where to generate the PHP5 apache configuration
• where to generate the PHP4 apache configuration

To recognize a directory whether it is a project to be enabled for apache we’ve the following rules for the directory name:

.php4|.php5[.extern]

Within the directory name is the distinction whether it’s an PHP4 or PHP5 project. That’s necessary because we’re running two instances of apache for each version of PHP so we can run both versions as apache modules.

The other directive, .extern, tells us that we want to public this project from our development server live on the internet. Why? Well, customers are everthing but patient, so it happens quite often we hand out URLs of our current development state to our customers. This also means we have to generate separate VirtualHost configuration for those projects.

The same rule applies to the user specific project directory, except that we don’t support .extern there, see below we.

Every project generated from those rules may have the following URLs:

project.dev.company.tld

For e.g. project.php4, not accessibe for customers

project.live.company.tld

For e.g. project.php5.extern

And for user specific checkouts:

project.username.dev.company.tld

In the end it’s dead simple. It took me about 2 days to gather the requirements, talk with the other developers how we could approach this and implement the soluation. Thanks to apaches Include *.conf directive it’s really easy to dynamically generate VirtualHosts and tell apache to restart.

Since ever developer within our company should be able to create new VirtualHosts config on demand, I provided a basic web interface which generates the apache configuration and restarts apache. Restarting apache from within PHP was a bit problematc, because you need to

• have the proper permissions to restart apache from user www-data (I’m using Debian)
• take care that running a PHP script which stops apache also terminates this very PHP script

To solve the permission problem I used sudo and creates a sudoers file like this:

Cmnd_Alias WWWEXEC = /data/www/intern/magic-config/generate.sh
www-data ALL = (root) NOPASSWD: WWWEXEC

To properly execute this script I had to put it into background immidiately so it is decoupled from the PHP script:

exec(“sudo /data/www/intern/magic-config/generate.sh&”);

The generate.sh shell script restarts apache.
At the moment I do not plan to release the code for two reasons:

1. I would need to get permission from my company, but if someone think he would really benefit from it, I may ask for it
2. It may be to specific anyway to our environment

Although HTTP_Client with its constructor provides a way to pass custom headers, the User-Agent header is also set inside HTTP_Request (create by HTTP_Client) which overrides any earlier value.

Here are some observations from my first steps with the new PDO extension.

Good:

• Exception-Safe (with PDO::ERRMODE_EXCEPTION)
  I wonder how one could every seriously write good application without exceptions (i.e. proper and predictable error handling)
• Simple, easy API
  The API is so easy, it has so less methods and therefore is easy to grasp. It may all back in complex situations but that I cannot tell that at the moment.

Not so good:

• Bound parameters/values not working as expected
  I’m not yet sure if it’s because I use pdo_odb or something else. What I tried, I couldn’t get it to working, no matter which way I tried. So I had to revert to using variables direct in the SQL statement.
• Crashes
  PDO has the bad habit that it crashes PHP where it can. Since I’m under Windows and I’ve no Windows C IDE I can’t help in debugging this problems myself but can only try to come up with reproduceable scripts. PDO seems to completely go havoc when you use the PDO::FETCH_LAZY attribute on PDO::query(). With havoc I mean that it throws back to you errors which aren’t a direct result of using FETCH_LAZY. I observed that I got two different kind of exceptions (Yes, I do love them) when using FETCH_LAZY. Both were Microsoft Access Driver problems, but they didn’t showed up once I stopped using FETCH_LAZY. One problem was error code 1311 and the other 1310. The former has something to do with running out of memory and the second one with an invalid table id.Then it seems, unreproduceable in small scripts, that it crashes when doing clean up at the end of the script. So basically, you’re doing your thing and when the script ends it gives you the send report to microsoft dialog

But, there’s one thing I really miss: editor split view. I’ve been using it for years in Vim: split horizontal, split vertical, make a quad-view; whatever. And I also discovered, having outline view or not, I’m not much less faster than splitting a window in Vim and searching for the identifier to jump to the declartion. And still see where I’m currently in my code.

I’m using these commands to create the CA:

openssl genrsa -des3 -out ca.key 1024
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

then I used these commands to create the client key/cert:

openssl genrsa -out client.key 1024
openssl req -new -key ca.key -in client.key -out client.csr
sh sign.sh client.csr

The sign.sh script is part of the libapache-mod-ssl package in Debian sarge.

At this point I end up with a client.crt.

When I now compare the modulus of the key and the crt file, they differ and I get the following error in apache:

OpenSSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch

In fact I discovered that the modulus in the csr already differs.

$ openssl rsa -noout -modulus -in client.key
Modulus=BF30F9CAA7C092CE...
$ openssl req -noout -modulus -in client.csr
Modulus=BF4E6276BF5CDFC7...

I actually was using these steps a year ago in another environment and it worked.

The openssl version I’m using is OpenSSL 0.9.7e 25 Oct 2004.

Any ideas?

What I didn’t expected is that this also affects the behaviour of the UNIQUE index. Before the change, the words ‘Grossschlögl’ and ‘Großschlögl’ where different. Now, after the change, the behavour due to my changed character set was, that these words where suddenly equal. And during an import I couldn’t import both words into the table because the column is a unique column. To successfully finish the import I had to temporarely use the old latin1 character set.