Hacker News Reader

Comment by dijit | Hacker News Reader

If your goal is to fully utilise the hardware you have then doing some deterministic sharding on top will likely be good enough.

Honestly, redis makes pretty sane tradeoffs, it's not worth the added complexity to add multi-threading as it would almost certainly slow it down while it does locking, and redis isn't typically CPU bound (except potentially the LUA stuff, but that's up to the user), so being multi-threaded doesn't really help much.

If you need multi-threading, there are other solutions, but of course they are slower w.r.t latency and throughput, since that's the trade-off.

View on HN

Have you checked DragonFly? It's multi threaded and modern Redis, it blows Redis away in performance by an order of magnitude.

Some performance number here - https://www.dragonflydb.io/blog/scaling-performance-redis-vs...

As always, "performance" is not just one metric you can measure and it'll "blow" away the competition in all use cases.

For example, if you care most about latency, Redis is still the way to go, while DragonFly seems better at throughput. But, tradeoffs vs tradeoffs and all that yadda yadda.

> For example, if you care most about latency, Redis is still the way to go, while DragonFly seems better at throughput. But, tradeoffs vs tradeoffs and all that yadda yadda.

DragonFly is better at latency too. The latency numbers they are showing are measured at the high throughput. If you were to reduce the throughput, the latency number would be even better. From the same post:

> This graph shows that the P99 latency of Dragonfly is only slightly higher than that of Redis, despite Dragonfly’s massive throughput increase – it's worth noting that if we were to reduce Dragonfly's throughput to match that of Redis, Dragonfly would have much lower P99 latency than Redis. This means that Dragonfly will give you significant improvements to your application performance.

There's an ongoing thread about Dragonfly here - https://news.ycombinator.com/item?id=36018221

Reply on news.ycombinator.com