Redis got replaced by Valkey FYI. It still has the same problems except for being driven by AI marketing, and even if you are doing AI you will find it has useful features, like vector lookup.
In praise of memcached
81–90 of 113 posts
Re: In praise of memcached
#82This kind of thing tends to happen a lot with open source projects or programs that are maintained long term. As the codebase grows, it inevitably starts supporting things that weren't part of the original plan. More features mean more users. Some stick to the old stuff, some embrace the new, and eventually certain values become the de facto default, not really optional anymore. Take Redis. Turn off AOF and it works…
"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.
Re: In praise of memcached
#83Earlier quoted context omitted.
At many companies (I want to say most), Redis is seen as an actual durable production database and operated that way, not just as a cache that can disappear at any time. It's not unreasonable for a new dev to assume this unless told otherwise.
Sure, but that is an internal documentation failure not a redis failure. It feels incredibly unfair to blame redis for that.
No one assumes memcached is persistent or Postgres isn't. Why does only Redis/Valkey have this problem?
Re: In praise of memcached
#84Earlier quoted context omitted.
Sure, but that is an internal documentation failure not a redis failure. It feels incredibly unfair to blame redis for that.
No one assumes memcached is persistent or Postgres isn't. Why does only Redis/Valkey have this problem?
Because it can be both depending on the command line flags sent to it.
Also, because it's so easy to setup, most DevOps/SREs/Ops just chuck into production without reading about which flags to set because we are not informed it's a requirement until 11th hour.
Re: In praise of memcached
#85memcached is about a bazillion times faster than redis at doing the simple KV cache job. it’s got threads. it’s highly optimized to do its one job super well, where redis is more a arbitrary shared Python heap kinda thing with all the data structures and single thread and whatnot. at notion we use redis for a lot of things, but actual caching we leave to memcached
Threads are not free - they allow to use more CPU cores but if you load is not too high than with a single thread memcached uses less CPU than with multiple.
Re: In praise of memcached
#86WHEN do you move to Redis/Memcached? None of my projects have exceeded 1000 rps at peak, and in none of them have I felt the need to move from unlogged PostgreSQL tables to Redis. Just trying to get a sense of where people draw the line.
As always it depends. Are there noticeable bottlenecks/latency in the app? No? Why pre-optimize then?
Look at this image: https://cs61.seas.harvard.edu/site/img/storage-hierarchy.png
At scale, the timing and order of magnitude increases in latency can add up. Caching the most requested data the higher you go can keep up performance (at added cost). On a busy website, that could be things like session tokens or other data that is part of every request. On a landing page, it could be images or other static data (I mean, you'd use a CDN for this, but you get the idea). Database calls can be expensive (computationally and IO wise), so if you can recalculate and cache certain operations, you can keep up.
Also, do you really need memcached/redis? If you have session affinity, you can also have nodes each keep their own caches in memory, with the caveat that if there's a failover, you'll have to re-fetch the data. Redis/memcached would be more of a shared cache, for things that you may not want to interrupt the user if they hit a different front-end endpoint.
It also doesn't have to be a cache. We've used redis for distributed task coordination as a shared state with the caveat that if something happened to redis, we'd just restart the task.
TL;DR If you need a SHARED cache when the performance of your app slows down enough that the cost of caching makes up for it.
Re: In praise of memcached
#87WHEN do you move to Redis/Memcached? None of my projects have exceeded 1000 rps at peak, and in none of them have I felt the need to move from unlogged PostgreSQL tables to Redis. Just trying to get a sense of where people draw the line.
You could ask the opposite question too, could you move your bespoke Redis/mcd workload to a boring old database? We have some workloads from 100k-1M ops/s that I would love to streamline but the load is too high. So... 100k in this case? :-)
Re: In praise of memcached
#88Earlier quoted context omitted.
I am currently in the process of starting a project with Flask, SQLAlchemy, Celery. Say more about why I should avoid Celery and what to use instead.
What are you using Celery for? Do you need to be able to recover from a reboot or crash with your queues intact? Is it a distributed system as opposed to a single machine? Do you have complex multi-step workflows? If you answered no to each question, just `import Queue from queue`.
> What are you using Celery for?
Things like provisioning, deploying, and eventually destroying cloud instances (VMs) on-demand when a user buys a specific service.
> Do you need to be able to recover from a reboot or crash with your queues intact?
Yes, I expect the queue to be durable.
> Is it a distributed system as opposed to a single machine?
Currently, everything runs on a single machine. But I expect it will eventually have to be split up. Although I do not expect it to be massively distributed or very complex.
> Do you have complex multi-step workflows?
Depends on what you mean by complex but Multi-step, yes.
Re: In praise of memcached
#89memcached is about a bazillion times faster than redis at doing the simple KV cache job. it’s got threads. it’s highly optimized to do its one job super well, where redis is more a arbitrary shared Python heap kinda thing with all the data structures and single thread and whatnot. at notion we use redis for a lot of things, but actual caching we leave to memcached
Can confirm it's not that much faster at k/v. 300 vs 350 microseconds per read on average. The single thread thing doesn't matter much since it's not cpu bound, it's reactive I/O
Re: In praise of memcached
#90Earlier quoted context omitted.
I don't want my cache to silently fail. 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
> silently fail Mature ops would be tracking cache hit ratios right? It sounds like memcached would be really good in a use case where you really just need an optional stateless pure cache with absolutely zero rope to hang yourself on. A use case where "cache hit ratio" is the goal, not "fiddly in-memory data store".
> absolutely zero rope to hang yourself on
Yeah I thought so too. Google "memcache slab starvation" if you want the long story