I’ve been pulling my hair out for the last few weeks working on migrating enotes.com over to a new server setup. The new setup runs on dual Opteron AMD64’s. AMD64’s are relatively new 64-bit processors that offer lots of processing power for very little money.

There are a few things you should pay attention to when running Apache, MySQL and PHP under these 64-bit processors.

1. Bugs in MySQL (8555 and 3483) cause INSERT statements to hange indefinitely. A temporary work around is to add skip-concurrent-insert to your my.cnf.
2. A bug in Apache’s regex.c engine causes problems with mod_rewrite on AMD64 (31858). You can either upgrade to Apache 2.0 or use the patch supplied in the bug to fix Apache 1.3.33. I continued to have problems running our code in 64-bit mode so I chose to run Apache in an i386 chroot using debootstrap (thanks to Jeremy)
3. A bug in PHP’s strtotime() function (30215) causes the function to return huge numbers instead of -1 on error. This boned Smarty’s date_format on my sites.

Those were the serious problems I had getting things up and running. Other than that things appear to be running smoothly. The following is the work around I submitted to the Smarty mailing list concerning PHP’s strtotime() bug.

Why not put a check into the smarty_make_timestamp() function? It’s predictable in that it returns huge timestamps (3441718022400 is an example). The check could (and should) be removed once PHP fixes what appears to be a fairly simple bug.

So, until then, what do you do? Well, I’ve put together a simple fix. In plugins/shared.make_timestamp.php around line 51 there is something like this:

    $time = strtotime($string);
    if (is_numeric($time) && $time != -1) {
        return $time;
    }

Change that to:

    static $endOfTime;
    if (!isset($endOfTime)) {
        // End of 32-bit UNIX time - 1
        // 19 Jan 2038 at 03:14 and 7
        $endOfTime = mktime(3,14,6,1,19,2038);
    }

    $time = strtotime($string);
    if (is_numeric($time) && $time != -1 && $time < $endOfTime) {
        return $time;
    }

This fixed my problem since the function fails in a predictable format on my Opteron box. Of course, it will break if this code is still running after Jan of 2038.

Works on Apache 2.0.53/PHP 4.3.10 under Debian GNU/Linux (2.6.8-10).

I now work for a large site. It’s not a place I haven’t been before, but I’m definitely getting back into the swing of running a large (we’ll do over 10 million requests during our busy months). We’re in the middle of migrating our websites in house onto larger servers that we’ll manage ourselves. It’s a daunting task because our company runs lots of smaller sites we’ve either picked up or somewhat abandoned along the way. These sites were written in older versions of PHP (probably PHP3) by the owner of the company as he was learning PHP. As a result I’m having to go back and fix include paths, etc. as we migrate to the new server, but how exactly do you automate the task of checking a site with hundreds to tens of thousands of pages for parse errors?

A friend of mine, Ian, who I do a lot of “bouncing off of” had a great idea. Basically, you turn on log_errors in your php.ini file, tail -f /path/to/error.log | grep PHP and then run a garden variety link checker against your site. As the link checker crawls your site it should trigger parse errors that will show up in your error file.

There you have it. A simple and easy way to check a large site for parse errors. Turn your error_reporting to simply be E_ALL to find notices and other problems in your code.