5 ms·
Shameless plug for in-language storage. I've found that using a fast language/framework with a local cache gives you most of the advantages of a shared cache li
by nullwasamistake 7y ago
Shameless plug for in-language storage. I've found that using a fast language/framework with a local cache gives you most of the advantages of a shared cache like Redis without all the complexity. This feature feels like a tacit admission of that.
In "fast" languages (C# Java Go Rust Cxx) allocation tends to be fairly efficient so you're not wasting tons of space keeping objects in RAM.
These fast languages can max out the network interface most of the time using the right frameworks. In them, memory storage is also over 100x faster than remote like Redis.
Now if you've got something in PHP or Rails that can only manage 100 requests/second remote caches make tons of sense. The network overhead is nothing compared to how slow the language is. This advantage erodes when you're closer to native speed and local memory access is 1000 times faster than retrieving cached data over network.
TLDR: Redis and alike make sense when your language or framework is slow and the bottleneck is CPU use. They don't give you much when networking and memory bandwidth are your bottleneck because the language runs near native speed.
- sk0g 7y agoYeah but this doesn't work with something like microservices, or even Kubernetes based deployments, right? It might take you 3, 40, or a 100 tries for the same request till you hit a node that has your data cached. It could work with extremely high req/seconds, though in an unpredictable way.
- heavenlyblue 7y agoTo be fair, what does it take you to write a simple caching microservice based on protobuf or similar?
- sk0g 7y agoA lot more knowledge in the relevant space that I have. I could spend a week or two learning necessary information, analysing our use cases and then implementing it finally (which I would never get the time to, from a business perspective). Or I could use an off the shelf product that is probably better than whatever I could come up with, given, even, unrealistic amounts of time to perfect it. I could come up with something more suited to our use case only, but the moment the use case changes, I'd wonder why I didn't just go with Redis. I haven't actually looked into a DIY method though. I just know I want something like Redis for our user table, because it's hit a lot, and the traffic tends to be repetitive.
- heavenlyblue 7y ago>> A lot more knowledge in the relevant space that I have. Relevant to what? You've already got a microservice mesh, which means you've also got a microservice architecture that's supposed to handle all of the RPCs. Adding a layer of Redis on top is probably going to introduce more entities into the system and make it less homogenous.