In praise of memcached

If you happen to find yourself in a sysadmin position, or a position where you
just so happen to maintain someone’s
infrastructure, chances are that at
some point in time the topic “we need a cache” comes up.

You think for a moment and reach out for Redis, because you’re used to it, it’s
fully featured, and it works! You remember it being a good, solid cache, and you
wonder which new features recent releases have brought, and head to its
homepage:

Your agents aren’t failing. Their context is.

Inquiring agents want to know:

How can I use Redis Iris as a real-time context engine for AI apps?

Right, so probably something with AI^{. This is sort of understandable, because
Redis is a company that wants to make money.}

Anyways, Redis homepage aside, you deploy it, and off you go – your trusty
cache. You hand the connection string to the people who asked for it, and off
you go.

Few months later

After a while, it turns out that cache.set("key", "value") is a really simple
abstraction, and definitely easier than INSERT INTO table VALUES ('key', 'value'). People start treating the REmote DIctionary Server as something
that’s always there, something that persists data, something that is a
database.

You don’t know this. Your ops colleagues don’t know this. Therefore, your
alerting doesn’t know this either, because you assume that people treat the
cache as something volatile.

You find out that this has been going on when you happen to do something to
Redis. Maybe you upgrade it, maybe you move it to another node, maybe your cat
hits the eject button on your RAID0 server’s HDD tray.

The issue isn’t that Redis doesn’t have persistence, the issue is that usually,
Redis is brought into a stack as a cache, and it is run with the assumption
that people treat it that way.

Usually, by the time you realize this, it is already too late, and Redis is too
intertwined in the app to really leave its place. Instead, you have the eternal
pleasure of maintaining it and monitoring it like a pet.

Enter memcached

First off – what’s a memcached? Easy, ask its website:

What is Memcached?

Free & open source, high-performance, distributed memory object caching
system, generic in nature, but intended for use in speeding up dynamic web
applications by alleviating database load.

Wow, first sentence on the page, even with code examples. And look at those cute
little mascots at the top!

Memcached is also a cache, similar to Redis. Chances are that you’re using a
framework like Django, which supports pluggable
caching and allows you to
switch between different caching backends.

But why should you use memcached when it has much less features than Redis?
Here are my reasons for why these days, I will always prefer memcached over
Redis:

• Dealing with memcached downtime is incredibly easy, because client
  libraries generally ignore connection exceptions. For instance, a simple get
  will just return the default value (or none) if the server is down.

• Clustering memcached is wonderful, because memcached actually has no
  clustering built-in. To “cluster” it, you configure the client library with
  multiple URLs^{, and the client will select the target instance based on
  hashing the key. If a client-side call detects an instance as done, it
  removes the node from the
  hasher.
  After a certain time, the client will automatically attempt to reconnect and
  use the dead node.}

• memcached “solves” the whole persistence issue, because it does not persist to
  disk. It is therefore a perfect fit to just being scheduled as a stateless
  workload wherever you desire it.

None of these things are impossible with Redis, it’s just that memcached’s
architecture in general more leans towards these directions, which makes it
much, much more straightforward from an operations point of view.

But because of memcached being such a relatively simple application (plus the
fact that you can run dozens instances of it with ~64 MB cache size and close to
no overhead), if I need a cache these days, I usually reach out to memcached.

That said, a lot of “database too slow” problems actually begin their life as
“query too slow” or “missing indices”, so be a kind person and help your
developers with optimizing their queries.

Also, if you’re curious about some of the decisions behind memcached, the
blog contains interesting posts, with one
published just in May: “How Long Does That Response Take… For
Real?”.