Technology

Yesterday Salvatore released the long-awaited native Redis Cluster solution as part of Redis 3.0. It takes one specific approach to building a cluster that has operational implications - clients need to know which Redis master node to talk to. The server will redirect, and can be asked directly, when the client submits a command and the client will then need to ensure it connects to the appropriate master. Essentially it is like client-side hashing where the server tells you the results.

Like most industries computer programming has cycles. One of these cycles is how we write or compile programs. We fundamentally have two methods: static vs. dynamic. Neither is perfect. Because each has benefits and drawbacks the wheel is slowly turning between which is perceived as “better” or is more common. There are changes afoot right now which to me signal the wheel is turning away from the current preference and moving toward static.

In the previous installment I discussed topics and approaches to preventing your Redis instance from becoming slow.

Now it is time to go into ways of measuring it.

Right from the beginning I’ll tell you I received an electronic copy of the book in order to do the review. Rest assured the only consideration that buys is me doing the review. I am not affiliated with this book in any way and receive no additional consideration relating to it.

Running a Master/Slave replication with Redis is common, but has a few things you might not think of from a configuration management standpoint. One of these is synchronization of live configuration changes from master to slave. This article addresses the gap and how to close it.

As I am afforded the privilege of speaking with many people and companies using Redis in a variety of use cases from simple caching to multi-terabyte sized setups the one topic I am asked to address more than any other is performance. Redis is different in how you approach performance. In many, if not most, database servers you try to improve performance. With Redis the goal is to not slow it down. This is a very different approach and requires a different mindset to take advantage of it.

Look around the web for how to make your website better and you will find no end of articles, many contradictory. Look more specifically to Wordpress and things don’t change much. What does change is the strategies - mostly around caching and getting around terrible plug-ins and themes which seem to avoid performance mindful markup layout like a plague to be fled from in terror.

What you don’t see is a challenge to the fundamental way WP, and to a similar extent most publishing platforms, handles the basic web page. But what if we threw away the modern web page concept? Are there benefits to be had? Is there a way of making web pages which conserves bandwidth, CPU cycles, DB queries, and latency? I think so. And the answer may be a bit surprising.

For a while now the buzz is about being cloud. Whether it is apps in the cloud, services in the cloud, or being a cloud provider you can’t seem to escape this buzzword lately. But given the recent releases and direction the “major players” are talking about, I have to wonder if we are entering a stagnation period. Or perhaps, to borrow a phrase from economics, perhaps stagflation.

Working with Redis can be done with the usual mindset, but approaching it from a different mindset can reap significant rewards.

In Wordpress Responsiveness Part 2 I wrote about WP Supercache (WPSC) and how to tune it to your site. In this part I’ll talk about a separate plugin which works well with WPSC, CDN Sync Tool, and how it can improve your TTFB and load times dramatically.