As with any performance optimisation, the starting point is the traffic profile. The site sees between 300 and 1’000 pageviews a day, the top 8 pages account for 50% of traffic, the rest is one or two pageviews per page per day.
Given this spread of traffic, full page caching will take a long time to warm up, and will only improve the second hit to any given page, if the cached page still exists. I’d like to boost performance across the board, so I looked at using memcache. Several plugins exist which leverage WordPress’s in-built caching and store the data in memcache so it persists between requests.
The folks behind membase and couchdb merged into Couchbase. They produce couchbase server, which is memcache compatible (via a proxy known as moxi I learned) out of the box, with the added benefit of persistence to disk. One of my long term goals is to store Magento sessions for a long time in a mostly persistent cache, so I was keen to experiment with couchbase.
At first, I installed couchbase, fired up the memcached-redux plugin, and my load times went from ~200ms to >5s. Turns out couchbase doesn’t work out of the box, it needs to be configured via the web interface on localhost:8091. Done. Now load times are in the ~400ms range. Slower. I learn that the proxy is slower at getMulti() requests. So I installed the memcached plugin, which implements its own getMulti() in PHP. Load times improve slightly to ~350ms.
I then uninstall couchbase, install memcached, and try again. The memcached-redux plugin showed load times ~350ms, memcached plugin ~300ms with a couple of 4s responses thrown in for good mesaure.
Site was slower
Bottom line, using memcache was slower, whichever backend or plugin I tried.
On this server, we have plenty of spare memory / CPU and mysql has been given a generous amount of memory to play with. My guess is that for reasonably simple queries, when serving from memory, mysql performs about the same as memcache. Some old reading suggests mysql might even perform slightly better under the right circumstances.
Here, mysql is connecting via a unix socket while memcache is over TCP/IP. That alone might account for the performance difference.
Memcache has its place
Memcache has a whole lot of properties that make it useful in a wide range of circumstances. In fact, WordPress.com serve their cached pages from memcache via batcache. In an environment without a shared filesystem, memcache provides a distributed cache, which is the key to its success with WordPress.com. In fact the batcache literature specifically says that file based caching is faster on a single node.
On a single server with plenty of capacity, memcache is the wrong tool. I’m seriously considering varnish for sidebar and/or full page caching, it could really help with the busiest pages and I have some experience with it. But I think the next step will be to test APC. It’s a single machine, in-memory cache, so it could work well in this situation. Plus, the bytecode caching might have a positive impact.