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

61–70 of 113 posts

Re: In praise of memcached

#61

Post by hparadiz »

nchmy wrote: post #60
hparadiz wrote: post #48

Earlier quoted context omitted.

Modern rdbms databases already have an in-memory cache. For 99% of projects there's no actual difference. The round trip will end up around 12-22 ms in all best possible cases.

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.547 ms but that's only 1 direction. And a cloud space is hosting many servers, many routers, many switches, with lots of moving pieces so you're realistically adding 1.1 ms per subnet hop and in pretty much every data center that's probably 3-5 hops inside the LAN.

Re: In praise of memcached

#62

Post by stuaxo »

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…

"Communication itself isn't free, after all"

Off topic, but that's my problem with microservices, devs seem to be totally unaware of this.

Re: In praise of memcached

#64

Post by downsplat »

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.

At $WORK we never imported either, our cache layer for slow operations keeps its data in both the filesystem and a db table (used as a k/v store). The database helps coordinate thundering herd problems - this operation is being calculated by another thread, so just wait for it. Reads from the same server just hit the filesystem, and reads from another server hit the db once and then keep it in the filesystem. We could change the fs layer to memcached but so far it's working great.

Re: In praise of memcached

#65

Post by drchaim »

WHEN 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.

Re: In praise of memcached

#66

Post by AussieWog93 »

hosteur wrote: post #51
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…

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.

Things like chaining, groups, named queues just don't work the way you'd think they would. There's a lot of footguns and things require weird workarounds. Error reporting is misleading.

It's not bad enough where I had to pull it from the old project that used it, but going forward the new ones used a vibecoded queueing system that was genuinely more reliable than Celery but consumed a lot of memory (RSS inflation). Have then shifted to rq and at least for now it seems to "just work". You're better off doing anything custom/complex (like dependencies, or progress updates across multiple tasks) directly yourself in Redis anyway; since half the time Celery's less-well-trodden inbuilt features don't work the way they should anyway.

Re: In praise of memcached

#67

Post by calpaterson »

kylewpppd wrote: post #25

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" is the same thing as designing it to have a redis-friendly cache layout. The pattern for this kind of application cache is identical: "get, and if not there, calculate and set".

Re: In praise of memcached

#68

Post by AussieWog93 »

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.

No, you're right. Nothing crazy. But things like counting API usage across threads with INCRBY, or debounced HTML cache clears, or even an actual light db with persistence (AOF), and everything just working.

Re: In praise of memcached

#70

Post by calpaterson »

drchaim wrote: post #65

WHEN 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.

Mostly is no rule, adding a cache can just save you from having to buy a bigger database instance in many cases.

The most common first thing to cache is getting the current user, because this ends up being a very hot path for most stateless systems. Because you need to get the current user for almost every request, it's quite easy for getting the current user to be 50% of database load: first you get the user, then you do the thing. tada, user lookup is now half your app by volume

Post reply on HN