Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Garnet – A new remote cache-store from Microsoft Research

github.com

Post reply on HN
Print view View original

61–70 of 120 posts

Re: Garnet – A new remote cache-store from Microsoft Research

#61

Post by sumtechguy »

akvadrako wrote: post #47
moritonal wrote: post #36

Earlier quoted context omitted.

Could you expand on "It was the opposite of DNS: it was never a problem."? Feel like I'm missing some interesting history here.

It's weird since DNS is one of the most rock solid systems we have, with redundancy at every level. 1. Clients query a list of servers (IPs) and handle failover when you don't quickly get a reply. 2. Most of those servers at the root and TLD level are actually anycasted from multiple locations globally, so you connect to the closest instance. 3. Those instances are often clusters of physical servers. The big ones hav…

In my years of doing this sort of thing. I only had it really be DNS once. The issues I usually see blamed on DNS is when DNS is 'abused' to do things like load balancing and the TTL is very small. Then you need goofy things like 'sticky sessions' and what not to work around that.

Re: Garnet – A new remote cache-store from Microsoft Research

#62

Post by deskamess »

jeremycarter wrote: post #53
Weryj wrote: post #49

Orleans will love being bundled with this

Each Orleans node could have a Garnet node, I can see the Aspire configuration now

I am just happy there is a native Redis-like available on Windows. I believe there is another RavenDB replacement but this one is 'more' official!

Is it possible to use Aspire locally or is it just a cloud only 'framework'?

Re: Garnet – A new remote cache-store from Microsoft Research

#63

Post by robertlagrant »

mbreese wrote: post #51
moritonal wrote: post #36

Earlier quoted context omitted.

Could you expand on "It was the opposite of DNS: it was never a problem."? Feel like I'm missing some interesting history here.

It’s just a common saying “the problem is always DNS”. When you have a weird networking issue, the problem always seems to be DNS. Either some misconfigured DNS entry or DHCP giving you the wrong server address, etc… And then the problem is confounded by the fact that, ironically, DNS works so well that we don’t think of it as a primary point of failure. So inevitably, when there is a DNS problem, it’s the last thing…

DNS, BGP, or branch prediction. Pick three.

Re: Garnet – A new remote cache-store from Microsoft Research

#64

Post by robertlagrant »

cpressland wrote: post #34

This looks really good. I hope ultimately this replaces the “Azure Cache for Redis” resource. It’s slow, it’s a fork of Redis made to run on Windows, and it takes nearly an hour to create an instance of it.

I don't know why they wouldn't just run Redis on Linux.

Re: Garnet – A new remote cache-store from Microsoft Research

#65

Post by balls187 »

blackoil wrote: post #31
theLiminator wrote: post #26

Earlier quoted context omitted.

Couldn't you just replace the CLR and JVM with llvm and gcc and then replace C with assembly and arrive at the same conclusion.

Now commenting beyond my expertise, I understand both ecosystems have developed orthogonally, C#/Java assumes code to be higher level and "dumb" and optimization are in library/CLR/JVM. While C/C++ are developed with code at lower level and developer making sure code is optimized. Now, I could be talking out of ass, haven't done enough C/C++ coding in over a decade.

You can write poorly optimized C#.

And the intel C++ compiler has provided significant performance for decades via optimization without needing to optimize by hand.

Re: Garnet – A new remote cache-store from Microsoft Research

#66

Post by trelane »

throwaway38375 wrote: post #52

Neat project, but I will be sticking with Redis. I trust Redis to not do something weird with their licensing or pricing in the future. Plus Redis has billions of production hours under its belt. It's easier to install and understand.

Maybe. Patents are certainly a question, because of the license. Microsoft has definitely been aggressive about patents.

Re: Garnet – A new remote cache-store from Microsoft Research

#67

Post by Thaxll »

whimsicalism wrote: post #6
west0n wrote: post #4

From the benchmark performance charts( https://microsoft.github.io/garnet/docs/benchmarking/results... ), the throughput of the GET command exceeds that of Dragonfly by more than tenfold. While 50% latency is slightly higher than Dragonfly, the 99th percentile is slightly lower than Dragonfly. Both the throughput and latency of Garnet and Dragonfly are far better than Redis, indicating that Redis may require a signif…

surprised to see a garbage collected language project (C# for Garnet) beat redis/dragonfly

Because it's not the language that matters here, the performance comes from the architecture of the storage among other things.

I've seen Go code best Rust one, really when comparing languages you should look at the same implementation, if the design is completely different its not really comparable.

Re: Garnet – A new remote cache-store from Microsoft Research

#68

Post by zimpenfish »

robertlagrant wrote: post #63
mbreese wrote: post #51

Earlier quoted context omitted.

It’s just a common saying “the problem is always DNS”. When you have a weird networking issue, the problem always seems to be DNS. Either some misconfigured DNS entry or DHCP giving you the wrong server address, etc… And then the problem is confounded by the fact that, ironically, DNS works so well that we don’t think of it as a primary point of failure. So inevitably, when there is a DNS problem, it’s the last thing…

DNS, BGP, or branch prediction. Pick three.

Stealing from the greats, "DNS, BGP, off-by-one errors, or branch prediction. Pick three."

Re: Garnet – A new remote cache-store from Microsoft Research

#69

Post by DonnyV »

I'm looking forward to see where they are using this in production.

"After thousands of unit tests and a couple of years working with first-party teams at Microsoft deploying Garnet in production (more on this in future blog posts!), we felt it was time to release it publicly" https://microsoft.github.io/garnet/blog

Re: Garnet – A new remote cache-store from Microsoft Research

#70

Post by surajrmal »

Thaxll wrote: post #67
whimsicalism wrote: post #6

Earlier quoted context omitted.

surprised to see a garbage collected language project (C# for Garnet) beat redis/dragonfly

Because it's not the language that matters here, the performance comes from the architecture of the storage among other things. I've seen Go code best Rust one, really when comparing languages you should look at the same implementation, if the design is completely different its not really comparable.

While true, gc tends to affect tail latencies as it can increase variance. Obviously not always the case, but without sufficient planning it's likely. Languages with less stop the world problems tend to trade it for throughput, however if the application is not CPU bound it doesn't matter. The same can happen in a non gc language where a similar lack of allocation planning is done, but it tends to be considered more carefully because those languages really put allocations in your face.
Post reply on HN