In praise of memcached
jchri.st
In praise of memcached
1–10 of 113 posts
Re: In praise of memcached
#2Oh God I'm tired of ai written thought pieces
Re: In praise of memcached
#3[flagged]
Re: In praise of memcached
#4Oh God I'm tired of ai written thought pieces
I don't see how this is AI-written?
Re: In praise of memcached
#5Oh God I'm tired of ai written thought pieces
I don’t think LLMs would write this:
“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.”
Re: In praise of memcached
#6Oh God I'm tired of ai written thought pieces
I don’t think LLMs would write this: “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.”
Or this:
“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.”
Re: In praise of memcached
#7[flagged]
I'm not really sure memcached optimizes for operational simplicity. The only time I've run it at scale, it would have low cpu utilization then unexpectedly hit lock contention and fall over without warning.
Re: In praise of memcached
#8Redis works great as a cache, but there are a few things you need to do in order to use it reliably as a cache.
1) Wrap your client library so that it's impossible to store anything without an expiry date. You don't want 6-months-old data suddenly coming up in your app!
2) Either turn off persistence, or use a separate database for the cache. In other words, don't mix volatile data with stuff you actually care about.
3) Set up a reasonable maxmemory value with an appropriate maxmemory-policy, so that Redis doesn't eat up all your RAM.
4) Resist the urge to use complex data structures. If you try to update a single field on an expired hash, you will end up with an incomplete object.
If you don't want all that hassle, then yes, Memcached probably works better out of the box.
Re: In praise of memcached
#9Memcached is meant to be a lightweight memory cache, which makes sense, but contrary to the article's claim that "Redis is brought into a stack as a cache, and it is run with the assumption that people treat it that way"—I have very very rarely experienced this. Redis is brought into a stack because (most importantly!) it's fast and (almost as importantly!) because it's simple. I don't think this article is written by AI, but (and I'm trying to be charitable here), it's just like.. dumb.
> 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.
This is a terrible idea in the context of things that might use Redis. If you use Redis with some kind of complex state (say, a document if you're working on a Notion clone, for instance), wtf even is a "default value"? In fact, I actually also want to know when the thing is down.
> Clustering memcached is wonderful, because memcached actually has no clustering built-in.
Yeah bro, this is yet another one of the reasons people use Redis: it handles consensus and clustering for you. What even is this article? It's a master class in straw-manning architectural decisions: most people use hammers as hammers, but screwdrivers make great hammers too, especially if you also need to screw stuff in! I mean.. technically true?
Re: In praise of memcached
#10Oh God I'm tired of ai written thought pieces
Somebody call Deckard.