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.

The above graph is far from typical, but I love that the box (the top one in this picture) can do the job when it needs to. This activity is a result of bulk record imports, web activity results in relatively little database traffic due to my use of Memcached and Batcache.

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

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

• memcached, a “highly effective caching daemon, …designed to decrease database load in dynamic web applications,” and the related PHP functions
• pspell PHP functions related to aspell and this pspell overview from Zend
• http_build_query, duh?
• current connected mysql threads * unix load average = system busy; reduce operations when $system_busy > $x

development, memcached, mysql, php, pspell