Speedy PHP: Intermediate Code Caching

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.

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

10 thoughts on “Speedy PHP: Intermediate Code Caching

  1. Back in the day, when the company I was working for was one of the early adopters of the Zend Optimizer, you sometimes got into situations where the cache would not recognize if you changed a source file included by the main file you were executing. Because that seriously got into the way of short development cycles, and introduced a number of “fake” bugs that vanished once you turned the cache off, we used to develop without the cache. That, on the other hand, changed the timing of each script, and we got more (or less) contention on the underlying MySQL DB.

    I guess what I’m trying to say is a) don’t believe this’ll solve every problem and b) I’d be curious about how other solutions or more modern versions of the Zend stuff work out. Not curious enough to try them out, though, I’ve left PHP behind for the most part 😉

  2. This all sounds incredibly important and I truly wish I understood it…because I know I need to be worrying about all these things on my blog too….HELP!
    Signed blogging damsel in distress in Marrakesh

  3. Pingback: » Easy MySQL Performance Tips

  4. Stumbled here by accident, and though it’s a year old now thought I’d clarify the ionCube PHPA license. It is and always has been free, but do note that it reached end of life some time ago and EAccelerator is probably the best choice these days although we do have a new performance product that has not been released yet.

    Back in 2001 when I created the PHP Accelerator it was a massive shock to Zend. There was APC and a few other opensource caches, but they were all 30% or so slower than Zend Cache. I’d been using PHP for only a few days when I realised that it was quite slow and that there had to be a way to speed it up, so I started looking at caching. I didn’t know about the other caches at the time, although when I did I realised that they were clearly missing a trick as their performance was poor in comparison to Zend.

    Following a frantic 3 weeks of development, PHPA was usable and the first cache to match or run faster than Zend Cache, with the crucial trick being to execute code directly from SHM.

    After releasing the PHP Accelerator for others to benefit, Zeev Suraski got in touch asking what the intentions were; he was clearly worried, and concerned that their monopoly on the PHP market was being threatened. As a gesture of good will I made a promise not to release the source, so it remained closed source but free and maintained for several years, and adopted by countless sites globally from hobby sites to large enterprises such as Yahoo.

    After steering the APC developers in the right direction to improve their cache, and with other developers taking an interest in PHP internals, more caches appeared over time and there are several choices. EAccelerator, a fork of the dead mmcache project, APC, and the promising newcomer XCache are all worthy. EAccelerator in particular benefits from some good code optimisation strategies, helping to boost performance further.

Comments are closed.