I would've liked to have seen why they chose Memcahce over something like Redis. While this is a nice overview it feels pretty light on details which I think for their apparent scale would be the really interesting part.
From what I can tell is they mostly moved to calling multiple keys at once instead of individually. The internationalization bit was was interesting as a point to consider, but hardly seemed like a real innovation more just a solid tip. Maybe I'm dense and missed something important...
Memory fragmentation isn't an issue with memcached like it is for Redis. Given enough uptime and object churn, redis will use all the memory on a server and trigger OOM's. This is because redis counts the total amount of memory used to store objects for its "max memory" limit. With enough object churn, boom.
Memcached uses its max memory configuration parameter to decide how much memory to allocate, and that's it. System memory usage never budges.
Basically it boils down to fragmentation vs slab allocator model, and I'll take slabs for stability.
Not necessarily -- unless it had clear perf benefits (and I don't know if it would). I don't think we have much use for the features, so no need to change unless there's a reason.
I'd be interested in reading a source to this claim because I did quite a bit of research on memcached vs redis a couple of years ago and the conclusion I came to was that redis's performance was at least comparable to memcached, but potentially even faster in the (then new) latest engine.
I've also found redis to be easier to manage than memcached and easier to scale too - which was one of the clinching points that sold that K/V DB to us.
Pragmatically, the performance of redis vs memcached is similar enough for most people that very few people would need to decide based solely on throughput and read time alone. For example our application would regularly see hundreds of thousands of concurrent users with several million keys stored and yet our redis server was barely taxed at all.
It has been a while but is that with Redis configured not to store things on disk and configured properly for the machine?
(Again) It has been a while but I remember from my own tests Redis being faster. Granted I could've been exploiting some of redis's data types that allowed for my contradictory results (which is what you're saying).
I'm in no way saying memcache isn't awesome. It is great, dead simple, and works like a charm OOB. I used it in production for years with no real issues (except multi key performance).
From what I can tell is they mostly moved to calling multiple keys at once instead of individually. The internationalization bit was was interesting as a point to consider, but hardly seemed like a real innovation more just a solid tip. Maybe I'm dense and missed something important...