WordPress Development

Looking at a WPMU Object Cache

In the good ol’ days WordPress came with a filesystem object cache but it was removed some time ago because it was a pain to maintain, and caused problems for some users, especially those using NFS. Nowadays there is an object cache built in, but the cache only survives for as long as a page is being served.
Other developers have taken up the challenge and produced object cache plugins to fill in the gap. There are the neosmart ones including a filesystem object cache and a memcached one (Read Andy’s notes before installing).

The neosmart filesystem object cache (and the others according to #988) don’t work correctly with WordPress MU so I dug up a patched version of the filesystem object cache I worked on a year ago to look for testers.

Download object-cache.txt, rename to .php and copy into wp-content/. It should start working automatically but if you don’t see files and directories in wp-content/cache/, make sure that directory is writeable by the webserver.

The neosmart version on which this one is based doesn’t handle switching blogs at all. Cache collisions occur with data from one blog’s options polluting the options in others. The version linked above should fix that but I’d appreciate some testing by others.

Oh, check out WordPress MU trunk now. I merged WP 2.8 beta1 and I’m fixing bugs. Please install and try it out on a test server! The get_option() and related code is using the same code as which is one of the main reasons I went digging into the object cache. It leans a lot more on the cache than previously. Please test!

WordPress Development

Want to test the new WP Super Cache?

I need testers. Several people answered my call on Twitter last week to help test WP Super Cache. Here’s your chance!

Grab the development version and install it in your plugins folder as normal. Some of the new features and bugfixes to look out for:

  • If your cache files aren’t being deleted add “$wp_cache_shutdown_gc = 1;” to the config file, wp-content/wp-cache-config.php. The plugin will do garbage collection at the end of page load instead of using WP Cron. It’ll only fire off as often as before.
  • Empty supercache directories won’t be created now.
  • Bad Behaviour supported is added. Just enable the plugin at the bottom of the admin page.
  • If you’re getting an error “Call to a member function get() on a non-object in .. cache.php” that should be fixed.
  • Incorrect supercache mod_rewrite rules were generated if your blog was installed in a sub directory and they’re fixed now as well but you’ll have to delete the old rules.

If all goes well, WP Super Cache 0.9.1 will be released before the end of the week!

WordPress Development

Want to test super speed caching?

Yesterday morning was one of those mornings. I couldn’t sleep, but not for want of trying. Around 5am our 17 month old baby wasn’t too keen on the whole notion of shut-eye. Instead I took him downstairs to feed him, and do a little surfing and hacking to pass the time until the sun rose.

Lucky for you that I did.

I discovered that WP Super Cache was compressing the page output twice! That’s right, it’s my own fault, but for over a year that little bug has gone unnoticed. I won’t bore you with details, but it’s fixed now and if you compare wp-cache-phase2.php from the latest release with that in the development version you’ll spot the differences.

In testing, I noticed that pages were generated more quickly. Sometimes twice as fast as before if everything else had been cached by the object cache. I even posted a message to the support forum asking people to try it out but the silence is deafening which is why I’m turning to the power of the blog post.

If you’d like to give this bit of code a go, grab the development version of WP Super Cache, test it, and leave a comment here. Before you install it, grab a few pages while not logged in and record the page generation time, then after install, check out the same pages. I’d love to hear if it improves things.

You could also try setting “$cache_rebuild_files” to 1 in wp-cache-config.php. That will enable some experimental code that moves supercache files out of the way when the page becomes stale but then restores them while the page is being rebuilt. That should help significantly on busy sites where lots of comments are made. It’ll be switched off by default because I don’t think it will benefit most sites, and will only result in more I/O. Check out this forum thread for further info.

If you’re interested in testing the plugin in the future, you could subscribe to the wp-super-cache-dev tag, where I’ll post development updates on the plugin.