Semiologic Cache 2.0 / new back-end part 1

Here goes with the back-end upgrade, part one.

Semiologic Cache 2.0 beta is up for grabs. Heaps of other plugins (and the two themes) got updated and are in RC status in the process.

This needs a bit more testing than usual, since I’ve been filing quite a few bugs on the WP front that related to the new features I implemented. To participate, switch a site or two of yours to use bleeding packages under Tools / Semiologic API Key, mass-upgrade your plugins, and upgrade the theme.

The performance gains are quite significant, to say the least.

For the most part, the plugin updates and the two theme updates are about conditional flushing of caches. For instance, the nav menus cache is no longer flushed if you edit a post without editing its title, caption, or permalink.

Semiologic Cache 2.0 is of course another story. Its previous version was a forked and bug fixed version of the WP Super Cache plugin. No longer.

2.0 was rewritten from scratch and is a completely different animal:

  • It requires PHP 5.0 to work; some features (the query cache) require as much as PHP 5.1.
  • The niftier functionality is only available on servers with memcached installed. This is not available on shared hosts; but if you’re on a VPS host, such as Hub.org, you can take full advantage of it. (I’ll get in touch with Marc so that Hub.org users get memcached by default on Premium VPS and above.)
  • So-called “Super caching” no longer occurs for non-key pages (i.e. everything except the front page, and singular pages). Semi-static caching takes over for other pages. This allows to expire the super cached pages automatically.
  • The semi-static cache can be handled by memcached. This allows sites who live on multiple servers (such as mine) to avoid lags related to the filesystem.
  • A query-level cache has been added for sites that use memcached; it significantly speeds things up for logged in users, provided they haven’t authored private posts.
  • A persistent object-level cache has been added. This speeds things up for much about everyone, by avoiding round trips to the database when none are needed.
  • An asset-level cache has been added. It reduces the number of server requests per page by concatenating javascript and css files.
  • A gzip-level cache has been added, at the apache level, for servers that support mod_deflate. This significantly reduces the size of the files sent to end-users whose browser support it.

In short, Semiologic Pro users are ready for the new indexing algorithm that Google is going to roll out early next year. As I write this post, the Semiologic Cache plugin combines the benefits of all of the available performance related WordPress plugins, and more.

It’s easy to use, too. And error proof — contrary to the previous, WP-Super-Cache based versions.

How it relates to the new back-end is this: I needed a caching plugin that scaled with a WP-based membership plugin, on a site that is load balanced. The former means we get multitudes of users who are potentially logged in on a site; this rules out plugins such as wp-super-cache.  The latter means we cannot use the likes of query-cache, since it’s filesystem based.

I haven’t tested Semiologic Cache 2.0 with WP Wishlist, from lack of a copy and license. But I 99% expect it to work as is on sites that use it.

Comments on Semiologic Cache 2.0 / new back-end part 1 Leave a Comment

  1. Nice progress Denis,

    Will it work correctly with pages containing dynamic content, like eBay auctions, coming from Ebay feeds?
    It means whenever page is visited/reloaded, feed will provide fresh content.

  2. Depends on how you set it up.

    If you stick to the query cache and no static cache, your site is, fundamentally, fully dynamic.

    If you add a static cache, you’re rock solid in the event you get slashdotted, but pages refresh every 12 hours. Or every 5 minutes, if there are new comments.

  3. Adding to the previous comment, keep in mind that if you enable the static cache, then you (as the post author) will see mostly up to date data. But your users might be seeing cached data that is as much as 12 hours.

    This actually is a big improvement over WP Super Cache, which the previous version of Sem Cache was based on — with that one, it would seldom get refreshed except manually.

Leave a Comment

The images that show near comments are Gravatars.

Support requests should be supported through the Support Page. Thank you.

Fields marked by an asterisk (*) are required.