caching

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.”

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.