WP Super Cache and APC

Donncha: from what I’m reading about Batcache, it looks like the cache does not refresh upon a post change/update, but only on an expiration date. Is that correct?

Mark, thanks for the info. I found this http://wordpress.org/extend/plugins/batcache/, but you’re the first person who differentiates between the plugin and the caching engine. I haven’t tried it yet, but I assumed that the caching engine and the plugin were one and the same – looks like a good WE project

Someone correct me if my understanding is inaccurate.

APC (or X-Cache) does what is called as PHP opcode caching. Normally, PHP reads the .php files and “compiles” them on the fly. Every time. That is obviously not super efficient. APC and X-Cache store that “compiled” opcode and hang on to it, which gives you a nice PHP speed boost.

APC also provides a single-server in-memory object cache. Key/value store. That doesn’t automatically give you anything in WordPress. For that, you need an APC object cache backend, which is a drop-in file called object-cache.php that WordPress will use to interface with APC. Now WordPress just uses this for its object storage… not for HTML output caching. For that, you’d need something like Batcache, which can use the Memcached or APC object cache backends to do persistent HTML output caching. Batcache is another drop-in file called advanced-cache.php, which WordPress utilizes to do an early “hand off” (so the caching can happen before WordPress fully loads).

But Batcache by itself does not tell posts to refresh when they’re changed. For that, you need the Batcache plugin, which tells Batcache (the advanced cache drop-in) to tell the APC object cache backend to tell the APC persistent cache to flush that page out.

1. Opcode caching (APC or X-Cache) — speeds up PHP in general.
2. Object cache backend drop-in (for APC or Memcached) — gives WordPress persistent storage for objects.
3. Batcache (advanced caching drop-in) — caches HTML using the WordPress object cache (#2).
4. Batcache helper plugin — helps Batcache (#3) tell the object cache backend (#2) to flush things when posts change.

Thank you Mark too, but for full picture – what about WP plugins: WP-Super-Cache (as I understand, its alternate of Batcache), APC Object Cache Backend, Memcached Object Cache? Is there any place for them in harness above? Or there exist substitutes?

davegregg, in some ways CloudFlare and WP-Supercache do something similar: caching static pages. That said, if you get hit by a lot of long tail traffic, it would be worth using database caching with APC (single server) or Memcached (multiple front-end servers) so that pages can be built faster before being offloaded to CloudFlare.

ATDBlog, when using GZIP, you typically trade bandwidth for CPU. The bandwidth savings mainly goes towards a better experience (through faster page load) for your users, but it doesn’t really help you (on ther server side) that much in terms of performance. Actually GZIP can consume much more CPU on your server, and that could get you in trouble with a shared host.

If you get enough traffic, and assuming that you are already using a cache like WP Supercache, Apache (or whichever web server) may not be able to serve the content (pages, images) fast enough, so requests will pile up and things will eventually grind to a halt.

I believe that the lowest hanging fruit is to use a CDN, which basically outsources all the static requests (themes and uploads) to another server. That in turns frees Apache from serving those static files which can represent 50% to 90% of HTTP requests. “Origin-pull” is the simple way to setup a CDN, and all you need to do is refer to the static content through a new URL like cdn.mysite.com, which will pull the original content from http://www.mysite.com and cache it there for a while (I use 1 week for images).

WP-SuperCache will help with the CDN support, in addition to caching pages as static files on your disk.

If you get enough traffic so that even with Apache can’t serve just the static cached pages, you will need to turn to solutions like scaling up by using a bigger server, or scaling horizontally by adding more servers. This is much more complex.

At the end of the day, shared hosting can only do so much, and if you have even a small VPS, you could have a more exotic solution like Varnish, that would take care of the traffic spikes to a limited number of pages. If you get organic traffic on thousands or tens of thousands of pages, caching can only help you so much.

Also, if you site isn’t very dynamic, you may also consider caching the whole site (page + images) behind a CDN. It’s not always convenient, but it’s much easier than adding multiple servers. Keep in mind that if users press F5 in the browser (Refresh), the CDN will most likely go back to the origin server.

Hope this helps.

I don’t have much experience with QuickCache but from the looks of it, it runs on a similar principle than WP-SuperCache. Both are free.

As for GZIP, it’s just good to be aware that it can add stress to the CPU of the server, which may be a problem if you use shared hosting. This may not be a problem if you don’t have a lot of pages, so they may be generated only once and cached for a while (how many pages do you have?)

Fortunately, traffic spikes tend to focus on a single page, so those static page caching plug-ins should very much help. If one of them can use mod_rewrite to serve the cached pages (WPSC does), PHP won’t even have to be invoked, and that saves more CPU.

If you’re broke, and are using shared hosting, I’m not sure what else can be done.

Finally, remember that most of the pageload performance look at your site from a user’s perspective, so sure, they’ll ask for GZIp etc… As the site administrator, you also have to make sure that the pages can be built and served. It’s better to have a page that goes from 7KB to 21KB without GZIP — than no page at all because you ran out of CPU