101–110 of 113 posts
Maybe the client libraries can help by returning nulls 10% of time, in dev mode?
Burning memory for a pure memory/RAM service like memcached in today's environment is not going to work given the price of memory and especially for larger customers. Especially in cloud environments, it's going to be inordinately expensive so having hybrid solutions like Redis and their flash memory solution is probably going to be the compromise going forward.
That said, it's interesting when you learn in practice that sometimes an N+1 problem is actually faster as N+1 than trying to query across separate DBMS systems.
Earlier quoted context omitted.
"Communication itself isn't free, after all" Off topic, but that's my problem with microservices, devs seem to be totally unaware of this.
That's a decade old take. I don't think people are doing microservices and more.
I think I've seen all of the Redis/Valkey issues the author mentioned in production. * 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.…
var value = cache.lookup(
keyname,
() => db.query(...),
TimeSpan.FromMinutes(5) // or CacheOptions
);
I think I've seen all of the Redis/Valkey issues the author mentioned in production. * 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.…
Once someone decides they want to use redis as something other than a cache, you sort of do have 2 cache technologies anyway. You can't use a redis instance that is configured for caching for any other purpose (caching instance must have eviction, non-caching instance must not have eviction). You need a second redis with a different configuration. Honestly designing your app to have a "memcache-friedly cache layout"…
Back in the mid-2000s I worked on a scaled system that used memcache, and developers fell victim to all the exact same problems that are cited with Redis in the article.
- Developers attempting to endrun every one of the laws of distributed systems by using memcache.
- We had cache addiction, so the fleets got sized on the assumption that memcache was up, and then memecache had a problem, and suddenly we were DDOSed.
- write amplification, where one host would nuke a high-TPS key and every other host would DDOS a dependency to repopulate the key.
- hot keys which led to hot hosts and because we cohosted memcached with the service daemons, it meant mystery CPU spikes.
- stickiness from stale DNS entries causing memcache calls to blackhole.
Every single one was avoidable by using memcache in a better way, but the temptation to abuse it was too strong.
I remember one "fun" feature in Memcached, is that each client did it's own hashing/sharding system... and when trying to share cached values across platforms/languages in order to further reduce resources, that was fun... writing a custom .Net/C# client to match the Java implementation. This was in the .Net 1/2 timeframe around 2002-2003 before NuGet. That said, it's interesting when you learn in practice that somet…
This is specially visible in SQLite workflows.
The roundtrip for querying a local SQLite file is so fast that it's passable to execute N SELECTS inside a loop instead of a single SELECT with a JOIN, for example.
One other feature of memcache that is rarely mentioned is that all operations are O(1) by design, which is a conscious design choice from the authors: yes, it is limiting, but it also ensures no random stalls on simple operations, whereas Redis with its single-threaded core design can't guarantee that since you can run operations of arbitrary complexity (which surely as a developer make you feel very smart about it)…