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 WordPress.org 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!


You might also like

If you like this post then please subscribe to my full RSS feed. You can also click here to subscribe by email. There are also my fabulous photos to explore too!

Published by

Donncha

Donncha Ó Caoimh is a software developer at Automattic and WordPress plugin developer. He posts photos at In Photos and can also be found on Google+ and Twitter.

21 thoughts on “Looking at a WPMU Object Cache”


  1. hey donncha, did you ever get around to check out the object cache, that uses eaccelerator as the backend? just google for: eaccelerator object cache murmatrons

    and you’ll find it. I already tried psoting here with the link but it seems I get filtered as a spammer?


  2. Ovidiu – your comments were eaten by Akismet! Sorry!

    Did you try that object cache with MU? I haven’t tried it but it’s easier to poison the cache in MU because of the blog switching it does.

    I’d say the comments were eaten because that url is on a dynamic hostname. Wish he’d register his own domain or use WordPress.com/.org so I could stumble his site. I’ve tried several times..


  3. :-) I have been happily using this eaccelerator compatible version for quite a while, never noticed any problems. Cache works quite good and in combination with the mod of your wp super cache plugin he made, I fully trust eaccelerator .-)


  4. Hello Donncha, is this drop-in object-cache.txt still working with a multisite WP 3.0 installation? When I rename the file to object-cache.php and put it into wp-content, I see this message in my “Manage Plugins”-section:

    “The plugin 0 has been deactivated due to an error: Plugin file does not exist.”

    When I remove the drop-in, the message is no longer displayed.


  5. I’ve got the same problem Jan and oddly enough the performance issues I have with the back end go away if I remove the object-cache drop-in


  6. Hi,
    nice post
    In your version of object-cache, you used this line
    $data = unserialize(serialize($data));
    I really don’t get it why u r serializing and unserializing the $data in the same step, what changes will happen to $data after this step.

Leave a Reply