Article: Speeding up Existing Apps with a Redis Cache

An excerpt from http://www.sitepoint.com/speeding-up-existing-apps-with-a-redis-cache/, by Bruno Skvorc

We’ve gone through the basics of Redis in PHP before, but it’s time to cover a real life use case. In this tutorial, we’ll add it to an already deployed application to give the app the appearance of speed.

You can easily follow along by cloning the 0.6 release of the app.

The Problem

Before applying a solution, we need to have a clear definition of the problem.

The application in question, when executing a query, runs off to Diffbot’s API and makes it query the dataset. The subset is then returned and displayed. This can take up to 5 or so seconds, depending on the busyness of Diffbot’s servers. While the situation will undoubtedly improve as they expand their computational capacity, it would be nice if a query executed once were remembered and reused for 24 hours, seeing as the collection is only refreshed that often anyway.

“But what good is caching a single query?” you might wonder. It’s not like most people will search for one and the same thing often.

Well… as a matter of fact, not only has research shown that they will often search for one and the same thing (React is trending? Sudden influx of “react” queries), they will also very reliably search for prolific authors (or themselves). Considering the fact that implementing this cache costs us literally nothing (and actually reduces costs by reducing strain on the servers), adding it in is an easy win, even if it weren’t used as often as one would hope. There is no reason not to add it – it can only benefit us.

With the problem clearly defined, let’s handle the prerequisites.

Installing

First things first, we need to install Redis into both the development and production environment (note that if you’re using Homestead for local development, Redis is already installed, albeit v 3.0.1 at the time of writing).

We can do this via the operating system’s package manager like so:

sudo apt-get install redis-server

This is the simplest and recommended approach, but we can also install it from scratch and manually configure it. As per instructions on their website, this is done via:

sudo apt-get install gcc make build-essential tcl
wget http://download.redis.io/releases/redis-3.0.2.tar.gz
tar xzf redis-3.0.2.tar.gz
cd redis-3.0.2
make
make test
sudo make install

If you run into a fatal error mentioning jemalloc.h after running make just run make distclean and then make again. The make test command is optional, but helpful.

Note: If you’re reading this and version 3.0.2 is no longer newest, just adapt the commands to the newest version number.

To prevent some common warnings (on Ubuntu at least), we also preventatively run the following commands:

sudo sh -c 'echo "vm.overcommit_memory=1" >> /etc/sysctl.conf'
sudo sh -c 'echo "net.core.somaxconn=65535" >> /etc/sysctl.conf'
sudo sh -c 'echo "never" > /sys/kernel/mm/transparent_hugepage/enabled'

We also make sure the last command is added to /etc/rc.local just above exit 0, so that it’s re-issued on every server restart. Finally, we can reboot the server with sudo reboot and check if everything is fine by running Redis with sudo redis-server.

Finally, we need to make sure Redis starts after a server restart, so we follow their official instructions to get that accomplished.

Predis

We covered the basics of Predis before, and we’ll be using it in this case, too. Let’s install it with:

composer require predis/predis

Going further, the assumption is that we’ve absorbed the knowledge from the aforementioned introduction to Predis.

Since that post was published, minor differences were introduced (like a transition to namespaces) but the API we need is more or less the same.

Continue reading this article on SitePoint!

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.