from Hacker News

Garnet – A new remote cache-store from Microsoft Research

by saganus on 3/19/24, 2:56 AM with 118 comments

• by west0n on 3/19/24, 3:55 AM

  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 significant performance optimization.

• by KyleSanderson on 3/19/24, 7:23 AM

  Garnet’s storage layer, called Tsavorite, was forked from OSS FASTER, and includes strong database features such as thread scalability, tiered storage support (memory, SSD, and cloud storage), fast non-blocking checkpointing, recovery, operation logging for durability, multi-key transaction support, and better memory management and reuse.

  https://www.microsoft.com/en-us/research/blog/introducing-ga...

• by oaiey on 3/19/24, 9:18 AM

  It is interesting to see how Microsoft and the .NET team are building some very impressive hack-your-own-infrastructure project. Yarp is a reverse proxy/API gateway/whatever you do. Now Garnet for memory caches.

  Seems they have tons of internal need and are willing to share.

• by jiggawatts on 3/19/24, 6:17 AM

  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...

• by lxe on 3/19/24, 3:42 AM

  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.

• by caleblloyd on 3/19/24, 3:22 PM

  > Garnet being multi-threaded, `MSET` is not atomic. For an atomic version of `MSET`, you would need to express it as a transaction (stored procedure).

  I am having trouble understanding this. Why wouldn't they wrap that in a transaction internally for you, and make the command atomic? What other atomicity "gotchas" are there.

• by giancarlostoro on 3/19/24, 3:53 AM

  Definitely impressive, Microsoft Research comes out with some impressive projects from time to time, must be fun getting paid to do R&D. I wish big companies did more R&D style projects that benefit the industry in general. I sure hope a good company takes over Hashicorp if they're on the market to be bought.

• by mtmk on 3/19/24, 11:31 PM

  This is excellent news for people who needs to run Redis (or compatible in this case) directly on Microsoft Windows Server, without relying on WSL2. Previously, there was a Redis port available [1] (which is now in archive status) that had memory usage issues (mainly because of memory-mapped files AFAIK) and, of course, is no longer supported.

  It's also quite intriguing for me to see it's written in C#, as that's my native tongue. I'd be keen on dedicating some time to delve into the code.

  [1]: https://github.com/microsoftarchive/redis

• by DonnyV on 3/19/24, 2:35 PM

  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

• by ksec on 3/19/24, 4:07 PM

  Judging from comments here I guess no one uses memcached anymore ?

• by cpressland on 3/19/24, 8:28 AM

  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.

• by zokier on 3/19/24, 7:21 AM

  So what's the catch, where this doesn't perform well? Would be neat to see benchmarks on smaller instance types too, 72vcpu is quite chunky boi

• by legulere on 3/19/24, 6:37 AM

  > Garnet’s storage layer, called Tsavorite, was forked from our prior open-source project FASTER

  Would be interesting to know why it was forked, why the changes can't be incorporated and wether FASTER continues to be developed

• by Weryj on 3/19/24, 10:08 AM

  Orleans will love being bundled with this

• by throwaway38375 on 3/19/24, 10:47 AM

  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.

• by wokwokwok on 3/19/24, 5:00 AM

  After the aborted/abandoned attempt to port redis to windows (0) this feels like a second-try at the same thing, but first party.

  Of course, as a research project it doesn't have the same stability / support, etc. as redis, but I could easily imagine this rolling into a real product if it's popular.

  ...and as an MIT license, if nothing else, the code is a fun read. :)

  [0] - https://github.com/microsoftarchive/redis?tab=readme-ov-file...