This two year old post about Rasmus Lerdorf’s PHP scaling tips (slides) is interesting in the context of what we’ve learned since then. APC now seems common, and it’s supposedly built-in to PHP6. Still, I’d be interested in seeing an update. Are MySQL prepared statements still slow?

And that’s where Rasmus’ latest presentation comes in. We don’t learn anything about MySQL prepared statements, but we do learn how to find choke points in our applications using callgrind and other tools. In his examples, he can do a little over 600 transactions per second with both static HTML and simple PHP, but various frameworks — with many inclusions and function calls — can slow that to under 50 transactions per second (I suppose they’d explain that in a TPS report).

I’ve been working on MySQL optimization for a while, and though there’s still more to done on that front, I’ve gotten to the point where the the cumulative query times make up less than half of the page generation time.

So I’m optimizing code when the solution is obvious (and I hope to rope Zach into giving the code a performance audit soon), but I’m also looking at optimizing how PHP works.

Once upon a time, most of us ran PHP as a CGI, and every time a request came in, the PHP interpreter would have to launch, read/compile/execute the script, then spit out the result and shutdown. Now (hopefully) everybody’s running PHP as an Apache module, so all the time spent launching the interpreter, allocating memory and other resources for it, and then shutting it down and cleaning up after it, is done just once for each thread of Apache.

It might not sound like much, but I had a chance to compare CGI vs. module performance recently and found that a fairly simple, but frequently accessed script running as a CGI completely swamped a server as a CGI (creating a load average over 20), but was hardly noticed when running as a module.

But even as a module, the PHP scripts still need to be interpreted and compiled before they can be executed. And because of the way PHP works, this is done every time the page/script is requested.

Java programmers, among others, criticize PHP for this, but that small inefficiency is part of what makes PHP so easy to use (and popular). And that ease of use means people are building some really interesting apps worth scaling.

Anyway, there’s a solution to eliminate that inefficiency in PHP: intermediate code caching.

By caching the executable code generated by the interpreter, then the using the cached copy instead of the source script for the next request, you can enjoy the benefits of PHP’s easy development and compiled code’s fast execution time. A number of projects all promise anywhere from double to 10X jump in performance.

• ionCube PHP Accelerator
  This has the most recognizable “brand,” and some hosting providers even offer it, but it’s offered only in binary form and the license seems intentionally ambiguous (um, not free?).
• Turck MMCache for PHP
  Has a good performance chart, and is GPL’d, but development appears to have ended in 2003.
• afterBURNERr*Cache
  Yeah, I had to point to a page in the Wayback Machine, this project is dead.
• Zend Platform Performance Suite
  A commercial suite that includes piles of goodies, if you pay.
• APC: Alternative PHP Cache
  It’s under active development and includes Rasmus Lerdorf, the guy who created PHP, among the project leads. License: BSD-style (non-copyleft)

I haven’t actually tried any of these yet, but I’m looking for information and suggestions, and I’m likely to try APC, maybe even Zend soon. Just as soon as I make an app compelling enough (and large enough) to need it.

php, caching, acceleration, zend, apc, intermediate code cache, optimization, scaling, web applications