upvote

points

by crabmusket15 hours ago |
comments
upvoteby foobarian5 hours ago|
next
[-]
> absolutely zero rope to hang yourself on

Yeah I thought so too. Google "memcache slab starvation" if you want the long story

reply
upvoteby tempest_15 hours ago|
prev|
[-]
> Mature ops would be tracking cache hit ratios right?

Sure, and sentry integrates well with redis in python which is what I use primarily with redis.

I don't think memcached is bad, I just think its old and industry has moved to redis because it offers more while covering the previous use case.

Calling redis fiddly is a mischaracterization. For many use cases I have not had to think more than 30s to setup redis.

(also when I say redis I mean Valkey at this point, even if they are starting to diverge)

reply
upvoteby hparadiz14 hours ago|
parent|
[-]
There's basically zero reason to use redis. Pretty much every rdbms like mariadb, postgres, etc is just as fast. So then why redis? It's basically needless complexity in your system.
reply
upvoteby robotresearcher14 hours ago|
parent|
next
[-]
Postgres etc are more complex than Redis, are they not?

Does your argument assume you already have a database, so you might as well use it for your cache mechanism?

reply
upvoteby hparadiz13 hours ago|
parent|
[-]
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.
reply
upvoteby nchmy11 hours ago|
parent|
[-]
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.
reply
upvoteby hparadiz10 hours ago|
parent|
[-]
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.

reply
upvoteby nchmy5 hours ago|
parent|
[-]
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.

reply
upvoteby imp0cat14 hours ago|
parent|
prev|
[-]
Security. More precisely, the ability to secure access to redis with a password.
reply
upvoteby hparadiz14 hours ago|
parent|
[-]
Okay but I can do that with any rdbms and I can secure memcached too lol. So what? How is redis better than a fixed length table in MySQL?
reply