Menu

Subscribe

memcached

WordPress MU/MS Empty Header and Broken Image Bug Fixed

I just switched to a new server and found myself struggling with empty HTTP headers and broken or partial images. The problem is the memcache extension for PHP and WordPress MU/WordPress multisite’s need to reinstantiate the wp-cache after determining the correct blog for a given request.

Versions of the memcache extension prior to 3.0 go wrong somehow and it shows up when you try to do an HTTP HEAD request on a page (the result is empty) or enable X-SendFile support for WP MU/MS’ file handling (all the files and images in the media library will break). Upgrading to the the 3.x version (in beta since 2007) fixes the problem.

You may have to uninstall the old version before installing the beta, and installing the beta via PECL requires adding “-beta” to the package name. Here are the commands:

pecl uninstall memcache
pecl install memcache-beta

Fixing Batcache to Send The Correct Content-Type Header

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.

Installing memcached On CentOS/RHEL

Using info from CentOS forums, Sunny Walia and Ryan Boren, here’s how I got memcached running on my Dotster VPS:

Install libevent:

``` wget http://www.monkey.org/~provos/libevent-1.3e.tar.gz tar zxvf libevent-1.3e.tar.gz cd libevent-1.3e   ./configure make make install ```

Install memcached

``` wget http://danga.com:80/memcached/dist/memcached-1.2.5.tar.gz tar zxvf memcached-1.2.5.tar.gz cd memcached-1.2.5   ./configure make make install ```

We will start the server to use 30 megs of ram (-m 30), listen on ip 127.0.0.1 (-l 127.0.0.1) and run on port 11211 (-p 11211) as user ‘nobody’ (-u nobody):

``` memcached -u nobody -d -m 30 -l 127.0.0.1 -p 11211 ```

Get an error?

``` memcached: error while loading shared libraries: libevent-1.3e.so.1: cannot open shared object file: No such file or directory ```

Show it the path to the library:

``` LD_LIBRARY_PATH=/usr/local/lib export LD_LIBRARY_PATH ```

Memcached and WordPress

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.