Mark's blog

At work, we just migrated a database server from a Sun Fire V240 to a Sun X4100. This makes it the first AMD64 system we've put into production, and the performance advantage is staggering. I could post the benchmarks and various statistics, but I believe the following graphs paint a far more interesting and convincing argument for the price/performance benefit of Sun's AMD64 offerings...

Before (V240) CPU Utilisation

After (X4100) CPU Utilisation

All told, I'm impressed. The X4100 is ripping through queries at a phenomenal rate and is barely breaking a sweat. The V240 on the other hand was clearly struggling and was maxing out at 100% load. True, it's not a true like-for-like comparison, as it's pretty much impossible to do that across different systems and different architectures. But take a look at the price levels of these two systems - the V240 came in at around £7,500 for dual 1.5Ghz UltraSPARC IIIi processors, whereas for £4,800 you can get the X4100 with dual dual-core AMD 285 processors clocked at 2.6Ghz. Frankly, it's no contest. The only thing you don't get with the X4100 is another couple of disks which is no big deal as we've hooked it up to our SAN. However, even if you want to go for the X4200 which has room inside for 4 internal disks, you'd still only end up paying £5,100.

Blastwave PHP4 packages are available in /testing. These bump PHP4 up to 4.4.3, which is primarily a bug fix and security upgrade. It also fixes an issue with the packaging of the current 4.4.2 packages, which resulted in a non-working PEAR installation due to an error in the upstream source tarball.

I hope to get these packages released to unstable in the next few days - I've been running them for a few days here and there appears to be no issues, but as always any other testing or feedback is always appreciated. Make sure you head the warning at the top of the testing page, though!

At work, we're developing a brand new in-house CMS based on the Symfony framework. As it uses no mod_rewrite rules or other Apache dependencies and is a "clean break" for us, I figured it would be an ideal candidate for benchmarking under LigHTTPd, comparing it to Apache 2.2 in order to give me some statistics to compliment my last blog entry on the subject.

The results from the "ab" Apache-benchmark tool are pretty stunning - although I'm still at a loss as to explain just why LigHTTPd is so much faster. The configuration of everything apart from the webserver is identical. I'm running on a Sun Ultra 20 with 2Gb of RAM and Solaris 10 01/06. I have a shared document root, and two separately, identically configured zones, one running Apache 2.2.3 with prefork MPM, the other running LigHTTPd. PHP on both is 5.1.4, built using exactly the same compiler (Sun Studio 11) and flags for the Apache 2.2 SAPI and Fast-CGI build. Apache is using PHP loaded as a DSO, whilst LigHTTPd is running PHP through a socket, with 8 pre-forked PHP child processes :

fastcgi.server = (
  ".php" => ((
    "socket" => "/tmp/php-fastcgi.socket",
    "bin-path" => "/usr/local/php/bin/php",
    "bin-environment" => (
      "PHP_FCGI_CHILDREN" => "8",
      "PHP_FCGI_MAX_REQUESTS" => "10000"
    ),
"bin-copy-environment" => (
      "PATH", "SHELL", "USER"
    ),
    	"min-procs" => 1,
        "max-procs" => 1,
  ))
)

The page in question is just the initial login page to the CMS. There's no database access at all, so no communication with any system external to the web server. It's just straight Symfony processing, using the current trunk.

Read on for the results...

Continue reading "LigHTTPd and Apache - Symfony benchmarks"