How to speed up WordPress blog: REDIS

https://xpil.eu/onw 📋

Remember my recent post on mysterious improvement?

(Yep, if you don't read Polish you're out of luck. Sorry. Should have warned ya.)

I usually don't do technical WordPress advisory stuff here on my blog but this entry is an exception. Today we'll see how to make our blog run rather than just walk. From a slightly different angle this time.

Let's start from the most important question: is our blog too slow?

"Our?" What do you mean "our"? Do we have a blog in common?

Nope, this was just a figure of speech 😉 All right, once again: is your blog too slow?

How would I possibly know? What is "slow" anyway?

A hint: if your readers have to wait 2 or more seconds to open any of your blog's content then it is too slow. It takes 2 seconds for most people to start pondering on whether there are faster websites out there. In 3-4 seconds they will be long gone.

Xpil.eu blog has a long (and bumpy) history of performance optimization (or lack thereof). It's been up, it's been down. Overall it is not too bad although it happened to me once to host it in the US which was most likely the worst decision in my life since when I started to learn computer programming on a turtle with [simple_tooltip content='To be perfectly clear: it was turtle`s arse, not mine, with a pen sticking out of it. You kill two birds with one stone actually: you teach someone how computers work and also to love animals.']a pen sticking out of the arse[/simple_tooltip].

Another question is: how "dynamic" is our blog? How often does it change? Are there any elements (like widgets for instance) that deliver different contents with each page reload? And so on.

Why is it so important?

Because we are going to pick a buffering strategy depending on whether it is "dynamic" or not.

Buffe-what?

Am I not clear? Caching. Buffering. A short-term, close-range memory to speed things up.

PHP (which is the language of WordPress) has two major distinctive ways of buffering information: page-cache and object-cache.

Page-cache is "dummy" in the sense that it simply stores a full content of a website under a particular web address and if the same address comes up again in your browser, the end-user will see the very same copy of the page as they did the last time. No expensive queries on the server, no MySQL round-trips, no executing complex bits of PHP code etc.

Result: the page opens "instantly" as the response time of the web server is close to zero and the only thing we are waiting for is to push the content through the links between the web server and your browser.

This is a really cool method if we do not care about dynamic blog content.

And what if we do?

Well, there's at least two ways: either "teach" WordPress to recognize the fact that the page content should now be different (some WordPress plug-ins do a great work here actually), or - instead of page-cache strategy - we reach out for the object-cache method. Which is: rather than buffering the whole page at once, you buffer each element independently and control the "up-to-date-ness" of it, also independently. This allows to generate "static" elements quickly but also keep "dynamic" elements up to date.

Advantage: random quotes, hit counters and other crap like that will always display up to date, correct information.
Disadvantage: it works a tad bit slower ("something" has to happen on the server to figure out the dynamic elements and to refresh them).

Personally I prefer the latter. It is a tiny bit slower, true, but you do not need to sacrifice any functionality. And it is also more "elegant" i.e. in case you have to refresh page content, you only refresh the bits and pieces that actually need refreshing, and not the whole page (which happens with the page-cache method).

Well ok, now the question is: How to implement this?

How to implement this?

I'm glad you asked! There's plethora of possible answers (some of them presented here already): various caching plug-ins, memcached, JS/CSS minimalization, GZIP compression, cleaning up your plug-ins, image optimization...

I don't have a whole day, man. Get to the point!

All right, all right! 😉 The answer is: REDIS. Redis is a gem I discovered literally a couple of days ago and felt in love with it straight away.

Why?

Because it's simple, fast and robust.

OK, what is this whole rebis thing?

It's REDIS. "REmote DIctionary Server". In simple terms, it is a "dummy" key-value persistent data store so a close relative of Cassandra, HBase or Couchbase. Its main advantage is that it only uses RAM to operate. When it starts, it loads everything it needs from the disk, and then (except for a background, asynchronous thread saving data do disk every now and then) it uses RAM and RAM only. This makes REDIS incredibly fast (you never get a bottleneck on the CPU with REDIS, it's usually the RAM or network). On top of this REDIS has a nice feature of working in cache mode which means that when the available RAM fills up, it discards the oldest / least used items rather than going south.

This cache feature is exactly what is needed to make REDIS a great WordPress caching engine.

There are a couple of WordPress plug-ins working quite well with REDIS but if you enjoy getting your hands dirty with the "bare metal" solutions, I would strongly advise you to try a "plugin-less" approach. In fact it is just about installing and running the REDIS server at the OS level plus downloading a single PHP file into the main WordPress folder - and off you go.

I may write a more detailed instruction once. Today I'm only pointing you to a couple of places: place 1, place 2, place 3

Good luck!

Przeczytaj artykuł po polsku: PL

https://xpil.eu/onw 📋