Superfast performance boost (for non-beginners only)

Warning! This plugin is not meant to be installed by beginners. It’s not trivial to configure and relies on an external Redis server to do its magic. If you have never configured an application that relies on a Redis server, or never administered a Redis server yourself, this plugin is NOT for you!

Instead, as a beginner, you should rely on one of the many, many other caching plugins out there, some of which are very easy to configure and will give you enough of a performance boost.

That said, if you read this far, welcome, Advanced WordPress PowerUser? ??

As a non-beginner, you should know that caching pages to improve performance only goes so far. WordPress-generated websites are far more dynamic than that (unless, of course, your website rarely changes over the years).

Static page caching still gives a performance boost when your site has to serve a lot of requests in a short amount of time (i.e. several per second). Serving a static page directly through the webserver is the perfect choice for such scenarios: generate once, and the rest of the requests made in a short interval will never hit the database (nor even the PHP subsystem), but rather served directly from disk, or, even better, from memory.

But what about dynamic page changes that occur all the time, in slightly larger intervals of time? Consider how a visitor browses your site: they might navigate via the menu… but also wading through the related posts widget. Which are generated on demand (or close to it), usually presenting a random selection of posts within the same category or tag (or possibly even with a more complex algorithm). ‘Random’ means that WordPress cannot serve that bit of the page statically — it has to be pre-generated before it gets delivered to the user. If the user goes back, it’s reasonable to presume that a different selection is presented; in fact, site admins often want that behaviour by default.

Or consider simple search queries. A ‘search query’, as the name implies is a database query. You can cache the results of the most popular keywords, but… in most scenarios, it will be quite hard to figure out how common a query will be (before it has been typed in) and for how long it should be cached (which also depends on how often the site gets updated).

The same applies to things like sliders or image galleries. Sometimes, their order of appearance is fixed in advance (and thus potentially cacheable). But often it’s not. It may be random. It may follow an unusual combination of attributes or preferences. Whatever the reason, one should assume that most dynamically-generated content cannot be effectively cached as a static page — not for more than a few seconds, at least.

There are several (complex) solutions to address the shortcomings of static page caching and still ‘protect’ the database from freezing down under the sheer weight of queries to deal with dynamic content. The higher-end plugins usually implement a series of techniques, sometimes giving the WP admin the possibility to pick the preferred technique, and fine-tune it.

WordPress, however, is quite helpful in that regard. One possibility, besides static page caching, is to cache a page object. These can loosely be defined as components of the overall page itself — they can be widgets or content injected by some kind of plugin (often automated by the plugin owner & maintainer); WP allows integrating plugins with what they call the object cache.

The most advanced caching plugins out there (I’m not mentioning any names; if you are an Advanced WordPress PowerUser?, you know which they are!) have often the option to use the WP object cache as well (sometimes only on the paid version). These plugins, however, are all-in-one solutions; you cannot, generally speaking, cherry-pick the several layers of caching you can use, using different plugins for each. They also configure everything automatically according to the whims of the developer. This is usually a ‘good thing’ from the perspective of the technical support team — who, when asked why their configuration doesn’t work well, will simply request that the user turns off all plugins except theirs. This might or might not be an option in several (most?) cases. Also, it’s not guaranteed that the all-in-one solutions are the best in all cases; rather, they tend to excel on some features, while adding others merely as an afterthought. That is, at least, my own experience; your mileage may vary.

Redis Object Cache, by contrast, does one thing, and it does it very well. As the name implies, it ties into the WP object cache mechanism. Instead of writing a pre-cached object to disk (or to the database), however, it saves to a Redis server — which can be orders of magnitude faster (since Redis is extremely efficient at storing data, mostly holding it in memory) than writing to disk (not to mention writing to a relational database!). As a bonus, Redis can be configured with distributed replicas, which is essential when scaling up a webserver to handle more traffic.

While minimalist in its approach — Redis Object Cache just requires to know basic details to connect to Redis, the choice of database (Redis only has 16 available…), and an eventual key prefix to avoid conflicts with several WP installations on the same server. In fact, that option requires modifying wp-config.php and is not set by default (which drove me insane when installing Redis Object Cache on a second WP install on the same server!). Hopefully, the author will address this issue in a future release of the plugin, and, by default, chooses a reasonable prefix (such as the WP URL, for example, or, for shorter keys, a hashed version of the URL, or even a UUID generated on the spot when installing). To be honest, ‘fixing’ my mistake was as easy as to flush Redis (a quasi-instant operation) and configuring different prefixes for the keys; a simple operation, and a minute later, I had both sides happily storing their objects on Redis.

This was probably the most catastrophic scenario that may happen with Redis Object Cache if you are an Advanced WordPress PowerUser? ?? And the fix is simply to flush Redis. It won’t matter much anyway, since, within seconds, Redis will quickly fill its memory with new objects.

An added bonus is a nice graph that appears on the Dashboard, showing some rough statistics about the access to the Redis server — measured in single-digit milliseconds. That’s right. When rendering a page from scratch, speed matters, and you cannot afford waiting more than a few milliseconds for data to arrive from the cache, readily processed. To the best of my knowledge, no other caching plugin can achieve that kind of speed. Except, of course, for the Pro version of Redis Object Cache, which does some extra magic and manages to cut by half the access time (!). How that feat is accomplish is beyond my ability to understand; but for those mission-critical websites out there, where sysadmins are constantly tweaking the infrastructure in order to shave off a few milliseconds here and there for each page access — well, Redis Object Cache Pro may very well be worth the few dollars charged for it.

In my personal case, I don’t require almost-sub-millisecond performance squeezed out of Redis, so I’m more than happy with the ‘standard’ version. Its ‘limitations’ — absent from the Pro version — are not really an issue. I love its bare-bones simplicity — once properly configured and installed, that is — and the consequent performance boost, which, unlike what may happen with a plain old page-caching system, will benefit every user, even on a WP website with almost zero visitors: Redis Object Cache will — by design — also cache the objects for the WP backoffice. Everything that is an object — and that means every component of WP, including all those on the backoffice — will be cached. This makes a lot of sense during the design (or redesign!) phase, where admins will be constantly going to and fro the many WP options, spread across themes and plugins, until the design is finished. These are repetitive tasks — querying for the same article to be edited, or the same page template to load, etc. — which Redis Object Cache handles admirably well.

While I have deployed it on several websites on my (single) server — where Redis is locally installed and shared by a lot of other applications, including PHP itself (for session storage — another performance boost that is built-in into PHP if that option is configured), I’m well aware that my use-case scenario (mostly very low traffic websites) is perhaps over-engineered for the small demands placed on the overall system. Nevertheless, I was happy to see that the MariaDB behemoth — by far the most memory-consuming process that is constantly running, non-stop — was notoriously happy after I deployed Redis Object Cache: that seems to mean that the database is not being hit so aggressively as before. It’s hard to get a grasp of how important Redis Object Cache has been in keeping the overall CPU + Memory consumption at relatively low levels; my server simply hasn’t got enough traffic to be able to make a before-and-after comparison. However, I can see quite noticeable performance boots on the WP backoffice! In fact, on one website currently under development — which has around one thousand articles spread across more than a dozen categories — I have turned off all caching (to make sure that everybody always sees the ‘latest version’ under development) except for Redis Object Cache, which works so well and deals flawlessly with ‘dirty’ objects (i.e. those that have been changed through user intervention), unlike most page caches. The responsiveness has gone up 500% or more — but without a ‘serious’ test, using well-known benchmarking tools, I can only relay my visual experience, filtered through my perceptions; ultimately, I can only affirm that I perceive many things on the backoffice to be five times faster than before, but cannot guarantee that this will be the case for everybody.

What I can — and will! — recommend is to do at least one external test to your Redis-supercharged site, from one of the popular websites calculating metrics. You might get a very positive surprise!

In conclusion… for the low-traffic websites I manage (roughly two dozen), all running on the same server (which is quite decent, albeit being almost a decade old…), because I’m always fearing to be ‘slashdotted’ some day, this simple but effective plugin keeps my database server happy all the time — because it gets so little work to effectively do ??

This is the kind of “must use” plugins that every WordPress installation should have as default. Everybody enjoys faster speed and giving the database server a break!