I saw this funny TikTok trend about that one person at a coffee shop ordering a complicated drink with like 15 customizations. If you’re a barista, you know it’s time to go on a break when you see that one car pulling up in the drive-thru. Should’ve just made your coffee at home, bro!
In scenarios like these, a tool like Memcached (but for baristas) would be a lifesaver.
Memcached is a tool that stores frequently requested data in memory to stop apps and websites from asking the database for the same thing over and over.
Memcached makes processes faster and more efficient. And while it seems like just a small tool in the shed, it’s one of the more important ones. You’ll understand why I speak so highly of this tool when you’re done reading this article.
-
Navigate This Article:
Overview of Memcached
Let’s first break down what Memcached really is. To begin with, it’s an open-source tool. That’s one way of saying that its code is available to the public.
Anyone, including your cat or dog, can access it if they know what they’re doing. And they can use, modify, and even improve it if they so wish.
Secondly, Memcached is pretty much a storage box for data. It stores the kind of information you need to access frequently, but under one condition: it won’t keep it for that long.
That brings me to my next point. Memcached stores information in a “cache.” That’s just a fancy word for temporary storage.
So why do we need Memcached in the first place? Slowness is the problem here, and Memcached is the answer.
You see, most websites aren’t sophisticated enough to store information without a database. So when you first interact with a standard website or app, it sends a request to the server to provide whatever data you need.
Maybe you want more details about a product. Maybe you want to stream that new movie.
The server isn’t ready for that constant back-and-forth with you. And no, it’s not even being rude.
Put yourself in its shoes. How would you feel about being asked to pass the salt every five seconds during Thanksgiving dinner? When will you get a chance to enjoy your turkey?
It’s the same thing with Memcached — instead of passing the salt every five minutes, it puts the salt shaker somewhere everyone can access quickly enough. That place is what we call the server’s Random Access Memory (RAM).
Any developers or system admins in the house? Memcached makes your site or app run faster without much extra work. It’s especially useful for websites with high traffic. I’m talking about the kinds of websites where every second of delay can frustrate users.
Think of Amazon.com as an example. The eCommerce giant receives billions of monthly visits. Now you can imagine a situation where Amazon.com is super slow. That alone could result in losses worth millions or even billions of dollars if not handled properly.
If you’re a web architect, Memcached lightens the load on your database to keep the whole system stable and responsive.
Understanding the Basics of Memcached
This whole Memcached thing can be confusing if you don’t understand the basics. That’s what I’ll focus on in this section.
What Is Caching and Why Is It Important?
We can’t really talk about Memcached without mentioning “caching.” It’s like making mac and cheese without the cheese or the macaroni.
Caching is kind of a shortcut. It’s probably one of the few moments in life when taking shortcuts actually yields good results.
Here’s how it works:
It stores data temporarily in memory to avoid reloading it repeatedly from slower sources. This reduces latency (that annoying delay before data delivery), speeds up web response times, and lightens the database workload.
If you’re a Netflix subscriber, you’ve probably noticed that the movie posters load almost immediately after you’ve signed in to your account. Most of these posters usually load from memory and not directly from the server.
Even your own cellphone uses caching to remember words you frequently type. We call this technology autocorrect.
What Does Memcached Do?
A lot. That’s the simple answer.
The longer answer is that it “caches” memory to increase speed and performance. To achieve this objective, it stores small pieces of data, like strings, objects, or the results of database queries.
This system uses something called a “key-value structure.” Don’t let that fancy description scare you; I’ll break it down.
Let’s start with the key. This is exactly what it sounds like. A unique identifier, to be precise.
Then there’s the value. This is basically the value of the key. When you pair these two, you get a “key-value” structure.
I’m such a big coffee fan that the local Starbucks already knows my favorite order when I pull up to the window. But that didn’t happen overnight. I had to actually order the same drink for weeks for the barista to realize it was my favorite.
So now every time I walk in, this one barista already knows what I want and how I want it prepared.
The real-life barista, in this case, is an example of a cache. The ability to quickly recall my favorite drink is what caching is all about.
Do you get the difference?
Another thing to know is that Memcached operates like a hash map. Again, that’s just another flowery way of saying that it stores data in a way that makes it easy to retrieve quickly.
So instead of sorting through everything, it just goes straight to the key and pulls out its value. This entire process takes just milliseconds.
Key Features of Memcached
It’ll be unrealistic to imagine that Memcached does all this without help. Of course, it has some important features that work together to make caching possible.
- In-Memory Storage: By storing data directly in its memory, Memcached is able to process it even faster than when stored in a traditional hard drive.
- Scalability: If your application becomes the talk of town and starts getting heavy traffic, you can easily add more servers to handle the increasing data load. This strategy spreads out data, which makes it more available even if one server goes down.
- Simplicity and Speed: Memcached is lightweight and doesn’t come with a lot of dependencies. And because it doesn’t take up much space, it processes things faster.
- Eviction Policy: Memcached “evicts” data that is not being used frequently, also known as Least Recently Used, or LRU. That way, it frees up space and resources and allocates them where they’re needed the most.
The bottom line is that everything Memchached does focuses on creating faster data processing speeds. And it comes with many other factors that work together to make that happen.
How Memcached Works
We’ve agreed that Memcached does a lot. But how’s that even possible? Let’s go behind the scenes.
Memchached’s Data Storage Model
Remember the key-value combination I mentioned earlier? Memcached can’t really do anything without it.
That reminds me of that one time I was preparing to watch my neighbor’s cat for the weekend. Excited, I decided to get her some cat treats from Walmart.
Surprisingly, I just couldn’t find them, even though I’ve been to Walmart more times than I’ve been to the gym. I then decided to ask for help. The funny thing was that the cat food was right below my nose in aisle J10.
In this case, cat food was the key, and J10 was the value. Combining these two helps you get what you want much easier and faster.
That’s exactly what makes Memchached seem so special. In reality, it’s just more organized than most humans.
Understanding Memcached’s Eviction and Expiration
I also briefly mentioned the concept of eviction and expiration. Now let’s go into the details if you don’t mind.
I’ll (again) use Netflix as an example. And no, this isn’t a paid ad, nor am I a huge fan of Netflix.
The streaming service deletes movies after some time, especially if the subscribers haven’t watched the said movies in months. This is just a tactic to free up memory. And when you look at it from another perspective, that’s what eviction is all about.
Expiration is slightly different. I can only imagine it as a free parking garage. If it says “two-hour limit,” you’ll pay extra if you stay longer than that.
Similarly, Memcached can remove temporary data, like search results or session info, after a set time to make sure it’s not holding outdated content.
The Memcached Protocol
A protocol helps avoid confusion in the communication between the client and the server. Secondly, it’s much easier to figure out what’s not working if something goes wrong when you follow a protocol.
At the server level, the communication happens over TCP or UDP protocols. Here, Memcached operates via client-server architecture. What this basically means is that the client (the application) communicates with the Memcached server.
The discussion? What to store and what to evict.
And you can easily tell what these two are talking about just by studying the commands.
The command set, for example, adds data to the server. Get, on the other hand, “gets” or retrieves data. Delete is pretty much self-explanatory. Then there’s incr/decr for tracking things like counters.
The best thing about using Memcached is that it’s not so choosy. It works with almost every major programming language out there.
Non-Persistence in Memcached
Memcached is what’s known as a non-persistent, best-effort cache. This means that it doesn’t hold onto data forever. Also, it loses the cache if something goes wrong (like a server restart).
I want to make something particularly clear here before we proceed: Memcached stores temporary data only.
That explains why it’s always one minor inconvenience away from losing the said data.
Sometimes, the data stored in Memcached can get stale. This mostly happens when the main database updates it, but the cache misses the memo. This is where cache invalidation strategies come in.
They replace the cached data with fresh data at the right time. That way, users always get the latest information without any unnecessary delays.
Memcached vs. Other Caching Solutions
Not all caching solutions are created equal. I’ll do a quick comparison to prove this point.
Memcached vs. Redis
Here’s a simple table showing the differences between these two caching solutions:
Feature | Memcached | Redis |
---|---|---|
Simplicity | Lightweight, designed purely for caching. | More complex, supports multiple data structures. |
Data Structures | Only supports key-value pairs (basic strings). | Supports lists, sets, hashes, and more. |
Persistence | No persistence, loses data on restart. | Persists data to disk for recovery. |
Use Case | Ideal for temporary cache needs (like sessions). | Suitable for caching and long-term storage. |
Performance | Faster for basic caching tasks. | Slightly slower but more versatile. |
Use When | You need fast, short-term caching. | You need more than just caching |
Memcached is lightweight and simple. It only focuses on storing key-value pairs in memory.
Redis is a little more advanced. It has features that support complex data structures (e.g., lists and sets) and persistence. As a result, it’s mostly used to save data to disk.
Let’s say you just need fast, temporary caching without all the extra stuff; that’s Memcached’s job. But if your application requires more flexibility, such as caching sessions, queues, or data you can’t afford to lose when the server restarts, then Redis should be your top choice.
Memcached vs. In-Memory Caching in Databases
I’m going to summarize things in the table below, and then I’ll briefly explain the key talking points.
Feature | Memcached | In-Memory Caching |
---|---|---|
How it Works | Stores data in a separate cache layer (RAM). | Stores query results directly within the database’s memory. |
Scope | Caches anything (queries, sessions, objects). | Only caches SQL query results for that database. |
Performance | Reduces load on the database by offloading data. | Speeds queries but may slow the database if overused. |
Scalability | Scales easily by adding more Memcached servers. | Limited to the memory available in the database server. |
Data Flexibility | Can cache any kind of data, not just SQL results | Limited to SQL query result caching. |
Best For | Ideal for high-traffic apps that need fast access to varied data. | Databases with repetitive queries |
Maintenance | Managed separately from the database. | Requires tuning and maintenance within the database engine. |
Persistence | Non-persistent—data is lost if Memcached restarts. | Query cache persists as long as the database is running. |
Database-level caching keeps frequently used queries inside the database. A good example of this type of caching is MySQL Query Cache. Memcached, however, stores data in a separate memory layer. And keep in mind that this layer is completely independent of the database.
Separating the cache from the database has its own benefits but can also ruin your day, depending on the situation.
The good side of it is that Memcached reduces the load on your database. That explains why it processes database requests faster. The bad side of things is that there’s a high risk of losing data when it’s stored in memory.
Memcached vs. Browser Caching and CDN Caching
Here’s a little secret from Server-ville that you probably didn’t know: caching happens at different levels. And it also behaves differently depending on the level, as the table below shows.
Feature | Memcached (Backend) | Browser Caching (Frontend) | CDN Caching (Network Caching) |
---|---|---|---|
Location | Server-side, storing data in memory (RAM). | On the user’s device (browser). | On edge servers close to users. |
Caches | Dynamic data (e.g., session info, query results). | Static files (e.g., images, CSS, JavaScript). | Entire web pages, images, and videos. |
Purpose | Reduces load on the database for fast responses. | Speeds up page loading by avoiding re-downloads. | Minimizes latency by serving content from nearby servers. |
Scope | Affects backend operations (data retrieval). | Affects individual user sessions. | Affects content delivery across the network. |
Refreshes When | Cache expires or is manually invalidated. | User clears the browser cache or it expires. | CDN cache expires or when purged manually. |
Optimizing database-heavy applications. | Optimizing database-heavy applications. | Speeding up content on repeat visits for users. | Delivering large files or media with minimal delay. |
I’ve lost count of the number of times I’ve asked my clients to clear their browser cache in order to view the changes I’ve made to their websites. And sometimes, even after clearing the browser cache, some of these changes might take unreasonably long to reflect.
So what I usually do in such a situation is to clear the cache from the server. That works almost every single time.
Browser caching stores things like images and CSS locally on your device. Imagine if Instagram actually loaded every image from its servers every time you wanted to check what your friends were up to.
Don’t get me wrong here, though. It’s not just a social media thing. If you could replace Instagram with your favorite website, browser caching would still work.
CDN caching is when the system stores content on servers closer to the user. The goal here is to reduce load times. And the reasoning behind it is that it takes a shorter time to fetch data closer to you than swimming across the Atlantic for the same.
You can even use Memcached alongside browser and CDN caching. You don’t have to choose only one of these three. In fact, if you decide to go for both, you’ll create a multi-layered caching strategy.
The result? Faster access to both static content (via the browser and CDN) and dynamic data (via Memcached).
Use Cases for Memcached
It wouldn’t be fair to discuss Memcached without seeing it in action. Here are some common ways developers use it.
- Caching Database Query Results: This caching system can store the results of complex SQL queries. That way, it saves the need to repeatedly hit the database. This is especially useful for expensive queries that don’t change often. I’m talking about things like product lists or analytics data.
- Session Storage with Memcached: It’s much better to store a user’s session in memory than a database. You can log in and access data faster since the requests don’t need to travel all the way to the database. Instead, what you need sits right under your nose.
- API Response Caching: Memcached can also store responses from external APIs. This type of storage prevents the system from making repeated requests. That’s actually a good thing, considering that some APIs have call limits. To add to that, it speeds up the response times for API calls.
- Object Caching: I use Memcached to store frequently accessed objects when developing applications. These include things like user profiles when creating content management platforms or even product listings.
- Page Caching in Web Applications: Web pages tend to load faster when you access them the second time. Do you know why? It’s because of something called full-page caching. Because Memcached knows you’ve been on this page before, it’ll store the entire page in its memory. This, however, only works for static content like plain text and images. I wouldn’t recommend it for pages that need to be dynamically generated every time.
From the above use cases, we’ve learned that Memcached works in various scenarios. However, the main point here is that each one of these scenarios has only two objectives: to reduce latency and improve performance.
Installing and Configuring Memcached
Here’s how to install and configure Memcached on Linux, MacOS, and Windows.
Installing Memcached
Let’s begin with the installation and proceed to the configuration.
On Linux (Ubuntu/CentOS), you can install Memcached using package managers:
“`bash
sudo apt install memcached # For Ubuntu
sudo yum install memcached # For CentOS
“`
On macOS, install it with Homebrew:
“`bash
brew install memcached
“`
If you’re using Windows, you’ll need a precompiled version. The other option is to use Docker.
Next, install client libraries for your programming language.
For instance, for Python, `pip install python-memcached` should work. For PHP, use `composer require php-memcached.”
Configuring Memcached
Now let’s set everything up. We’ll start with memory allocation.
Here, we want to be very clear about how much RAM Memcached can use. Then, we’ll do something called port binding. It’s like telling Memcached,
“Hey, buddy, I want you to listen for all incoming connections via this port number.”
Tip: The default port number is 11211.
Once that’s out of the way, we’ll then set connection limits. This makes sure we can control how many clients can connect at once. You don’t want the server processing more than it can handle.
When the setup is ready, we’ll need to fine-tune it for better performance. This is where we increase memory limits if the cache needs to store larger datasets. We also set appropriate timeouts and choose what eviction strategies we want to use.
Some Linux distributions may have a default Memcached configuration file. You’ll find that at /etc/memcached.conf.
Best Practices for Memcached Configuration
If you want to make things work as they should, consider fine-tuning memory settings and monitoring usage regularly.
And if you’re working with a large-scale setup, you should consider configuring multiple Memcached instances across several servers to create what we call a distributed cache.
While at it, think about security. For instance, if I’m working with an app that’s only focused on U.S.-based users, I may decide to restrict access by allowing connections only from the U.S. Similarly, I can decide to zero it down to only trusted IPs.
I’ll then set up firewalls and, if needed, enable SASL authentication to secure the cache from unauthorized access.
Monitoring and Managing Memcached
Setting things up isn’t just enough; you’ll need to monitor and manage whatever caching systems you’ve put in place.
Monitoring Memcached Performance
Memcached monitoring mostly focuses on performance. You have two options: using tools like memcached-tool or running the `stats` command directly.
Whichever works for you, go for it. Personally, I find using third-party services like New Relic, Datadog, and Prometheus much easier. Besides, they tend to provide deeper insights and alerts.
Monitoring key metrics:
- Hit rate: Measures the percentage of cache requests served from memory (higher is better).
- Eviction rate: Tells you how often Memcached gets rid of old data to make room for new ones.
- Memory usage: Shows how much of the allocated memory is being used.
- Connection count: Monitors the number of active client connections to prevent overload.
- Request rates: Tracks the volume of incoming requests over time. You can use this info to identify and predict traffic patterns.
Beyond just monitoring performance, we use these metrics to plan when Memcached needs tuning or scaling.
Troubleshooting Memcached Issues
Most performance issues I’ve seen while using Memcached have been caused by hitting memory or connection limits or having keys expire too soon.
To fix these issues, you should adjust memory allocations or connection settings. You can also use logs to analyze cache misses and identify what’s slowing things down or causing frequent evictions.
Scaling Memcached
Now when it comes to scaling, I recommend doing it horizontally. This means adding more servers to expand Memcached’s memory. As you’d expect, the bigger the memory capacity, the more data this system can cache.
When dealing with a large database, you should consider sharding.
The sharding method splits a large database into small parts called shards to make the databases more manageable.
In a distributed environment, you can also implement cache synchronization. This system helps maintain consistency across all servers to prevent stale data or cache misses.
Best Practices for Using Memcached
Memcached will serve you right if you treat it well. I’m going to show you how.
Cache Invalidation Strategies
Here are some techniques for invalidating stale data.
Time-Based Expiration
You don’t want your cache to hold onto stale data. It’ll only slow things down. That beats the whole point of having Memcached. Instead, you should consider setting a timer that clears data after a certain period.
Manual Invalidation
Sometimes, though, you’ll need to manually clear the cache by clicking the reset button. I do that a lot when things start acting up. Growing up in a black household, my parents used to slap the radio when it started losing signal. And 99 percent of the time, this trick worked! We called it the reset slap.
Manual invalidation is like the server version of the reset slap. It’s not the best way to fix things, but it works when everything else fails.
Cache Stampede
This is when too many requests hit your system all at once, causing a stampede. To prevent this, you can use smart strategies like staggered exaggeration to set different expiration times for similar items. That way, not every piece of data expires at once.
Efficient Use of Memory in Memcached
Just because there’s plenty of memory doesn’t mean you should use it all up. I have a pretty good memory, but there are certain things I’d rather not remember or store in my mind.
The same thing happens with Memcached. It’s like packing a suitcase — you want to fit everything without overstuffing it.
You can avoid wasting memory by managing how much data goes in and setting reasonable expiration times. And if possible, you can compress data to fit more into the available space. If you’ve ever experienced the stress of packing a suitcase for a vacation, then you know exactly what I mean.
Balancing Cache Size and Database Load
Memcached isn’t a dumping site for just any kind of data. Yes, it can cache what gets used often, but don’t overdo it.
You still want the database to update in real time when needed. It’s like knowing when to keep leftovers in the fridge and when to make a fresh meal.
Secure Deployment of Memcached
You can’t afford to lower your guard in any environment involving an internet connection. All it takes is a malicious party with a laptop and some good hacking skills to bring your system to the ground.
Make sure only trusted devices can access Memcached. One way of doing this is by setting up firewalls and network rules.
And if you’re sharing resources in a multi-tenant environment, don’t be too generous; you may regret it later. It’s happened to even the best of us.
A Small Tool With Big Responsibilities
When all is said and done, Memcached is the one sidekick working behind the scenes to make sure websites and apps feel lightning-fast.
Even better, it’s easy to set up, scales well, and keeps your database from getting overwhelmed. And the best part? Users won’t even know it’s there.
You want them to think your app is really, really fast. Because it is.