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

11–20 of 120 posts

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

#11

Post by nurettin »

latchkey wrote: post #7
whimsicalism wrote: post #6

Earlier quoted context omitted.

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

I think it is rare, but isn't impossible. I remember in the 2000's watching someone do a demo of Java/JVM beating the pants off a C++ application. If I remember correctly, it was something about how the JIT was doing an optimization that you would have had to write assembly in order to optimize it to the same level.

There were coding competition benchmarks at the time putting javac against the underdeveloped gcc 2.95 of the time. The trick they did with java programs was to allocate a region of memory only once and reuse that whenever they needed more, simulating a stack. Then the programs were benchmarked as hot start and cold start. Hot start timings were used to bench against C++ programs. If the algorithm they used was better, this sometimes resulted in head to head or better performance.

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

#12

Post by latchkey »

nurettin wrote: post #11
latchkey wrote: post #7

Earlier quoted context omitted.

I think it is rare, but isn't impossible. I remember in the 2000's watching someone do a demo of Java/JVM beating the pants off a C++ application. If I remember correctly, it was something about how the JIT was doing an optimization that you would have had to write assembly in order to optimize it to the same level.

There were coding competition benchmarks at the time putting javac against the underdeveloped gcc 2.95 of the time. The trick they did with java programs was to allocate a region of memory only once and reuse that whenever they needed more, simulating a stack. Then the programs were benchmarked as hot start and cold start. Hot start timings were used to bench against C++ programs. If the algorithm they used was bette…

I remember that one too, but this one was not just the hot memory trick, which seems relatively easy. It was entirely JIT based, where the JIT happened to pick a better path than gcc.

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

#13

Post by hipadev23 »

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…

> Redis may require a significant performance optimization.

Redis is single-threaded, it’s simple and effective. I’m not sure it needs optimization, and we have 3 alternatives here.

Garnet however is the first alternative to actually outperform Redis at both low and high levels of concurrency, which is remarkable. I can’t wait to try it out.

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

#14

Post by amir734jj »

west0n wrote: post #5
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…

What surprises me the most is that this project is developed in C#, while Dragonfly is developed in C++, and Redis is in C.

If you look at the store code you see a lot of "unsafe" C# code (i.e pointer manipulation)

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

#15

Post by thayne »

latchkey wrote: post #7
whimsicalism wrote: post #6

Earlier quoted context omitted.

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

I think it is rare, but isn't impossible. I remember in the 2000's watching someone do a demo of Java/JVM beating the pants off a C++ application. If I remember correctly, it was something about how the JIT was doing an optimization that you would have had to write assembly in order to optimize it to the same level.

There are at least two reasons I can think of why a JIT language with GC can outperform C/c++:

1. Memory management with a GC often has higher throughput. With the downside that you can have high latency when a garbage collection occurs.

2. The JIT compilation can potentially do a better job of optimizing, because it has information about how the code has been run so far.

It is possible for c or c++ (or rust) to get get the first using alternative memory management strategies, and the second by hand optimizing, and/or using profile guided optimization.

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

#16

Post by rfoo »

blackoil wrote: post #10
whimsicalism wrote: post #6

Earlier quoted context omitted.

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

The investment in optimization in CLR or JVM can be huge as they impact millions of applications. While each C / C++ code will have to be hand optimized. Also limits on number of people in given time who can write optimal C code vs C# will also make managed code better.

Plus that it's easier to have unmanaged code in C# than in Java.

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

#17

Post by fulafel »

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

Seems it wins by using more sophisticated data structures & algorithms, instead of "tight code".

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

#18

Post by jiggawatts »

I just wish they had something like this embedded into Azure App Service, so it wouldn't be necessarily to use a remote service for caching.

For reference, something commonly used with IIS for ASP.NET apps was to have an out-of-process "session state" store, so that if the web app process restarted, users wouldn't lose their sessions and have to log in from scratch. Sure, you can put this somewhere central like SQL Server, but then every web page request sits there waiting for the session state to load before it does any processing at all. Session state is also typically locked in some way, which has all sorts of performance issues.

The typical current solution is to use Redis for both caching and session state, and this works... okay-ish. Throughput is high, sure, but Redis is a separate resource in Azure and is stupidly expensive. I really don't want to pay Oracle DB prices for something this simple. It's also a bit of a hassle to wire up.

In this article they talk about 300 microsecond response times, but that's irrelevant in any zone-redundant design because all Azure load balancers use random zone selection. So you'll have a web server picked in a random zone, then it'll contact a cache server in a random zone in turn. That server in turn may not have your key and have to contact yet another random zone to get your cache data! Your traffic ping-pongs between data centres. This introduces about 1-3ms of delays, up to 10x higher than the advertised numbers for Garnet.

The ideal scenario would be something like what Microsoft Service Fabric does: it has a "reliable collections"[1] service that runs locally on each host node and replicates to two other nodes. A web app can always read its cached values from the same physical host. The latency can be single-digit microseconds in some cases, which is thousands of times faster than any naively load balanced external service, no matter how well optimised.

I don't want 30% faster than Redis. I want 3,000x faster.

[1] https://learn.microsoft.com/en-us/azure/service-fabric/servi...

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

#19

Post by StepWeiwu »

nurettin wrote: post #9
lxe wrote: post #2

A drop-in redis replacement with rather impressive latency and throughput bench figures. Wonder what its like to operate in a non-azure stack in the real world.

Are you sure it is drop-in? I don't see any indication of xstream support.

The title does say that it can work with existing redis clients but it's unclear if they mean full compatibility.

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

#20

Post by vanhanenjjv »

StepWeiwu wrote: post #19
nurettin wrote: post #9

Earlier quoted context omitted.

Are you sure it is drop-in? I don't see any indication of xstream support.

The title does say that it can work with existing redis clients but it's unclear if they mean full compatibility.

https://microsoft.github.io/garnet/docs/commands/api-compati...
Post reply on HN