Oh God I'm tired of ai written thought pieces
In praise of memcached
21–30 of 113 posts
Re: In praise of memcached
#22Re: In praise of memcached
#23I stopped using memcached a decade a go in favour of Redis and now use valkey. Never felt the need to go back to memcached except when a legacy dependency needed it.
What do you think of the argument made in the article?
Re: In praise of memcached
#24Re: In praise of memcached
#25* Outages where Valkey had no memory policy, ate all the memory, and then caused write errors to its append-only file. Bonus points for another one where the disk itself was full, and AOF writes failed.
* 500s where Redis was fully expected to be live, running, and populated with data for every user, and no fallback to a slower path.
* Creative uses of sorted sets and other data structures which depended on the sets never being evicted.
Despite the observations from the field, I think it's still hard to recommend memcache ahead of Redis. It can be difficult to architect an app to have a memcache-friendly cache layout.
I'd almost guarantee a large enough team using memcache will find a way to need Redis. And then we're maintaining 2 cache technologies.
Re: In praise of memcached
#26I stopped using memcached a decade a go in favour of Redis and now use valkey. Never felt the need to go back to memcached except when a legacy dependency needed it.
OK. What do you think of the argument made in the article?
Clustering redis is not that hard even if you do it manually and I have only had to do it once.
I never use redis persistence and have a max size set with LRU or whatever the application requires.
With memcached I remember having to mess around the LD_LIBRARY path to link whatever python module I was using at the time
Re: In praise of memcached
#27Redis 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.…
> 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! No need for this client-side complexity, as you should be using `allkeys-lru`. FWIW, should likely be doing this anyway, as (generally speaking) all data stored in Redis is usually regarded as volatile because of what Redis actually is .
If you know this already, then you didn't need to read OP or any of this thread. :)
The problem is that Redis tries very hard to position itself as a persistent data store, with defaults that lean toward persistence (no default eviction policy). Beginners need to fight these defaults every step of the way if all they want is a cache.
Re: In praise of memcached
#28Memcached 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 b…
> wtf even is a "default value"? The article mentions the default value is a null, which would be the cue to run whatever computationally expensive op or query the db or hit the disk etc... that you would normally run if you had no cache to begin with. > but screwdrivers make great hammers too I don't know what your screwdrivers look like but that sounds like a rough time.
It works pretty well when you need to hit something with a solid object a couple times.
Re: In praise of memcached
#29Re: In praise of memcached
#30Earlier quoted context omitted.
> wtf even is a "default value"? The article mentions the default value is a null, which would be the cue to run whatever computationally expensive op or query the db or hit the disk etc... that you would normally run if you had no cache to begin with. > but screwdrivers make great hammers too I don't know what your screwdrivers look like but that sounds like a rough time.
Generally you can use the back of a screwdriver like a hammer. It works pretty well when you need to hit something with a solid object a couple times.