I’m a fan of Batcache, the Memcached-based WordPress full-page cache solution, but I’ve discovered that it ignores the content-type header set when the page is initially generated and re-sends all content with content-type: text/html. I posted a note about this at the WordPress support forums, but then I realized what the problem was: apache_response_headers() doesn’t return the content type, but headers_list() does.

The solution is to replace apache_response_headers() with headers_list() in the code, though headers_list() is PHP 5+ only, so it might be a while before we see a change like this committed. Still, I’ll shamelessly tag Andy Skelton (Batcache’s author) on it.

Elliott C. Back points to his use of object caching, WP-Cache, and MySQL query caching among the reasons why his site “is so much faster that yours.”

WordPress 2.5 is out (and the WordPress site got a facelift), and I’ve already upgraded MaisonBisson using SVN. The changes are exciting, and seem to reflect a tradition that’s developing in WordPress of delivering some really revolutionary features in the x.5 release.

The loss of file-based object caching was a bit of a problem, as my VPS’s load average jumped to over 30 pretty quickly after the upgrade. I tried Mark Jaquith’s apc-object-cache enabler and saw load average drop back to 2 or so, but I also saw tag and category names disappear and discovered other weirdness. Why it happened I don’t know, but I’m looking into it. Fortunately, NeoSmart’s file-based object cache replacement works perfectly and efficiently. (Mind you, Ryan Boren thinks WordPress caches should require more adventure.)

bSuite seems to work perfectly in 2.5, though the new shortcode API obviates one of bSuite’s coolest features: tokens. Still, it’s better to run with the herd, so I’ll be transitioning bSuite’s built in tokens to take advantage of the shortcode API soon.

One of the features that’s not received much attention yet, but is hugely valuable to those (like me) who are using and advocating for WordPress as a general purpose CMS, is the concurrent editing protection. That is, if another WordPress author is editing a story, you can’t save changes to it until that editor is done. The next step for this is to allow concurrent team editing in the way Google Docs does as well as versioning (versioning has been discussed as a feature for 2.6).

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

Ryan Boren wrote about using memcached with WordPress almost a year ago:

Memcached is a distributed memory object caching system. WordPress 2.0 can make use of memcached by dropping in a special backend for the WP object cache. The memcached backend replaces the default backend and directs all cache requests to one or more memcached daemons. You must have a memcached daemon running somewhere for this to work. Unless you’re managing the server on which your blog is running, you probably can’t run a memcached daemon, making this backend useless to you. The memcached backend is targeted at ISPs and those running WPMU. If you are using WPMU and distributing DB requests across multiple servers, memcached will come in very handy. Using memcached for a single blog isn’t really worth it. In my tests, it was sometimes slower than using the default object cache backend.

The plugin is here, a bug-fix note is here.

WordPress, memcached, optimization, caching