5 ms·
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 fo
by rubyn00bie 9y ago
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...
- tyingq 9y agoI don't think redis is available on AppEngine standard.
- rubyn00bie 9y agoAh! That totally makes sense. Thank you.
- benkraft 9y agoYeah, that's the main reason in practice. We also just don't need any fancy features.
- jedmeyers 9y agoWould having managed Redis on Google Cloud somehow influenced the decision?
- benkraft 9y agoNot 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.
- lukasm 9y agoDo you have any GAE resources (blogposts, github etc) recommendations?
- pstrateman 9y agoif you're strictly doing key/value caching memcached is faster
- rubyn00bie 9y agoIt 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).
- OriginalPenguin 9y agoSource?
- laumars 9y agoI'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.
- rak00n 9y agoRelated: http://antirez.com/news/94 http://antirez.com/news/94
- deleted 9y ago[deleted]
- 9y ago
- scurvy 9y agoMemory 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.