111–120 of 120 posts
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.
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.
Aged like milk.
Earlier quoted context omitted.
Meme this is referencing should be "It's always DNS config ."
Mostly. But it can also be DNS request volume, DNS cache expiry, DNS response times, DNS connection contention, DNS security, DNS error handling, or DNS client configuration. All variants of ‘DNS is working perfectly, just your expectations of how it will work in your situation are not completely correct’.
// wrote what might have been first commercial-use dynamic DNS server for a regional ISP in early 90s, invented an unreasonably effective geo+latency balanced anycast-like DNS for global video delivery network in 00s
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.
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…
I just faced an issue with redis this week. It was causing my Javascript heap memory to go bust. I thought it was a data leak in my code but it turns out the redis client was filling it up and I fixed it by simply adding a static delay every 1 million set operations so that the garbage collector had enough time to do its job. (I was stress testing for a total of 6 million set operations)
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.
Earlier quoted context omitted.
> 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.
Redis for 99% of the intended use-cases and companies will be just fine. It has always been rock solid when we used it. It was the opposite of DNS: it was never a problem.
DNS can fail when someone who is managing it have no idea what the hell they are doing and abuse it to do things it wasn't meant to do.
Earlier quoted context omitted.
This is a project from Microsoft Research, so I would worry a lot less about licensing and pricing than about lack of updates (either features, maintenance, or security ones)
I see this becoming an Azure service. But you are right, half of the Microsoft Research projects fizzle out within a year - unless used internally.
> Garnet has been of sufficiently high quality that several first-party and platform teams at Microsoft have deployed versions of Garnet internally for many months now.