Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In praise of memcached

jchri.st

Post reply on HN
Print view View original

91–100 of 113 posts

Re: In praise of memcached

#91

Post by noirscape »

Great post. Redis is just kinda overkill whenever I've had to use it. Memcached by contrast is very simple, fast and works without needing to do much fiddling with it.

One big tip I should recommend is to increase the default memory size limit to something more realistic for modern hardware (and arguably this should just be increased on the upstream's side as well, instead of making everyone reconfigure shitty defaults). It's very easy to exceed the memcached default key value, since it's just 1mb; the maximum size of memcached as a whole is 64mb, which is similarly very low. Outside of that, it works very well and the lack of persistence is great at making it not do things it's not supposed to do (which is a big problem with Redis' feature creep, the projects mainpage promoting AI drivel alone should point towards that.)

Re: In praise of memcached

#92

Post by nchmy »

hparadiz wrote: post #61
nchmy wrote: post #60

Earlier quoted context omitted.

If you're getting 12-22ms latency for your cache reads, the network is your bottleneck. If stored locally, you would get many orders of magnitude faster than that.

The network IS your bottleneck. That's exactly what I'm saying. APCu count=1000 min=0.000290 avg=0.000318 p50=0.000320 p95=0.000331 max=0.000992 ms Memcached count=1000 min=0.032422 avg=0.039714 p50=0.037211 p95=0.053261 max=0.091343 ms MariaDB count=1000 min=0.015680 avg=0.019541 p50=0.018485 p95=0.023855 max=0.103867 ms Don't even start a socket if possible. Now then do a traceroute. Even to my router it costs 0.54…

Gotcha. Yes, if you have your cache (let alone services) all across different machines, then this is all irrelevant.

The real question, which few ever ask, is whether your app actually needs more than one server. Servers are so insanely large (up to like 400 Cores) and powerful now that you can get meaningful scale on a single box.

If you can colocate the app and cache (and maybe also the db) on the same server, you can get many orders of magnitude better performance, regardless of which cache it is. Redis, memcached etc all can do 100k or more gets per second (dragonflydb etc claim 10x that due to multithreading).

Hell, with RAM being so expensive now and NVME so fast, sqlite is a VERY attractive option for cache. Plenty written about projects adopting it. Rails in particular is a champion of it.

Re: In praise of memcached

#93

Post by freediddy »

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.

Re: In praise of memcached

#94

Post by ritcgab »

0xCAP wrote: post #73
downsplat wrote: post #64

Redis is a great piece of tech but it suffers from trying to be good at two different jobs (persistent data structures, volatile cache) which should not be combined. And indeed in Redis itself they don't combine well - persistence is globally on or off. Personally I'd use memcached or some equivalent for strictly cacheing, and then bring on Redis with persistence if you need its data structures for e.g scoreboards. A…

> We could change the fs layer to memcached but so far it's working great. This so much. (Ab)Using a db table as a k/v store + the FS can do so much before even considering paying the price of setting up a dedicated caching store. I’ve fought countless foes in the engineering world when proposing solutions like yours just because (incompetent) people feel like caching should live in its dedicated store.

Because a database is a kv store. Most workloads won't tell the performance difference as long as the store works.

Re: In praise of memcached

#95

Post by dijit »

freediddy wrote: post #93

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.

Sometimes you just need some networked RAM, man.

Re: In praise of memcached

#96

Post by nightpool »

stackskipton wrote: post #84
inigyou wrote: post #83

Earlier quoted context omitted.

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.

You're making inigyou & OP's point for them. Redis is a great technology, but its design (supporting both persistence and non-persistence modes) makes it much easier to misuse and much more likely to be misused compared to Postgres and Memcached. That's a design issue, not just an internal documentation issue.

Re: In praise of memcached

#97

Post by a34729t »

jdw64 wrote: post #53

This 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…

AOF at scale causes failures, so you turn it off. Still makes a great cache though.

Re: In praise of memcached

#98

Post by smw »

alt227 wrote: post #54
AussieWog93 wrote: post #39

I've done a bunch of Flask work over the past couple of years - not full time but as part of the tech stack for my small eCommerce business. Have run into all kinds of footguns and weirdness with MongoEngine, SQLAlchemy, Celery (seriously, if you value your sanity, don't use Celery!), the Python stacks for Google, eBay and Shopify but never Redis. Perhaps that's because I'm not giving admin access to random people wh…

> every time I need to do something slightly weird, there's a sensible and well thought out way to achieve it. In my world cache systems like memcached and redis are just that, a cache to put and get from. Possibly use some invalidation system like tagging. What can you do with a cache system that is 'wierd'? What are people doing with caches other than just caching data? Genuinely interested.

Can do fantastically weird stuff with Lua scripts in Redis/Valkey

Re: In praise of memcached

#99

Post by boesboes »

WJW wrote: post #79
alt227 wrote: post #57

Earlier quoted context omitted.

> moving window rate limiting So does that mean you are tracking how many times data is being entered into redis, and rejecting it if the entry rate is too high? Why would you not track this before, at the point of calculating the data to enter into redis, rather than querying redis to see how much data is entered in a given timeframe? Again, genuinely curious as to the reason for architectural decisions.

Not GP, but I think they mean usecases like limiting how many times any given IP address can access an API to a certain amount of calls per minute. For example, you might want to restrict login attempts to at most 10 per minute per IP to prevent people trying out lists of common passwords. This is fairly easy to do if your apps runs on a single server, but many companies run multiple servers and load balance requests…

Spot on! It was for a decently sized SaaS app; 10k+ request per minute & and a LOT of spam traffic from china a.o. we needed to limit. The app ran across 10+ servers, this is also why we put it in the app using redis and not with something like nginx rate limiting.

I don't exactly remember how i implemented it, but it basically did a single call to redis to count the request for the IP and check the limits.

Another usecase where the more advanced data types & operations of redis are usefull, is for job queues, since you can atomically move a job from the 'queue' to the 'processing' list, thus preventing loosing jobs if the processor crashes after pulling it orso. But we do run all those on persisted redis stores, for safety :)

And if i would do it all again, i'd probably just use postgres for anything i want to keep when things crash. Redis just kinda lives between a 'real' database and a pure volatile kv-cache

Re: In praise of memcached

#100

Post by functional_dev »

gnz11 wrote: post #71
foobarian wrote: post #12

Earlier quoted context omitted.

The memcache slab pools are a leaky abstraction that you may end up having to manage operationally, and it's another way Redis is simpler.

Agreed. Memcache is great until you get into the business of having to configure slabs. Most people just reach for redis at that point.

I always used memcached without knowing how it stores things.. never knew about the slab thing.

It is more sophisticated than grab memory per item.

This helped be to understand it better - https://vectree.io/c/memcached-internals-slab-allocation-lru...

Post reply on HN