Valkey/Redis support offloading of io processing to special I/O threads.
Their goal is to unload the "main" thread from performing i/o related tasks like socket reading and parsing, so it could only spend its precious time on datastore operations. This creates an asymmetrical architecture with I/O threads scaling to any number of CPUs, but the main thread is the only one that touches the hashtable and its entries. It helps a lot in cases where datastore operations are relatively lightweight, like SET/GET with short string values, but its impact will be insignificant for CPU heavy operations like lua EVALs, sorted sets, lists, MGET/MSET etc.
Dragonfly supports both epoll and iouring, and polling engine choice is quite orthogonal to its shared nothing architecture. I do not think that Valkey or Redis will become fully multi-threaded any time soon - as such change will require building something like Dragonfly (or use locks that historically were a big NO for Redis).
I apologize. I must say that my tone, as you rightly wrote, was inappropriate.
Indeed, I am the lead developer for Dragonfly. As such, I am deeply concerned with the performance aspects of our product. Dragonfly claims to be a drop-in, better performant replacement for Redis and Memcached. Every test & benchmark we've run on multiple cpus reinforced that. I've never faked or tweaked any of these benchmarks. That is, of course, not an excuse, and is why I opened by apologizing. I'd like to take this opportunity, if I can kindly ask so, to learn what made your results differ so much from ours. I'll personally try to reproduce what you described. If you could also reach out to me, I'd be happy to learn more about the environments in which you've conducted the aforementioned tests.
I understand what you are saying. How would you suggest to present it then?
Dragonfly is not faster than Redis when running on a single cpu. It can not be, just because it has the overhead of the internal virtualization layer that composes all the operations over multiple shards (in general case). But Dragonfly can scale vertically with low latency and high throughput unlike other attempts of making multi-threaded Redis that used spinlocks or mutexes. So how do we demonstrate the added value?
1. We removed the FAQ page
2. You are right, I need to shut the fuck up and let self-righteous hn crowd with torches do what they do best - find a weakness, and push it until they get bored and switch to beat another builder. You asked me about my perspectives and priorities? These are my priorities: https://github.com/dragonflydb/dragonfly/graphs/contributors
3. The first thing I did was on this thread was to apologize for having FAQ with such content.
You are an exception, then :)
But I still stand by the claim that fragmenting your stateful workload (i.e. Redis) into bunch of processes instead of having a single endpoint per instance is an acceptable approach in 2023. When your processes are excessively tiny, their load variability overshadows their average load. This imbalance results in unpredictable pauses, latencies, and Out of Memory (OOM) issues. This primarily occurs due to the absence of resource pooling under a single process. While it's challenging to exhibit this issue via synthetic benchmarks, it's certainly present.
Because we focus on building the most
awesome datastore and you should decide whether you prefer having your store designed by good marketeers or good engineers.
hmm and ships are designed to sail, yet you use planes to cross atlantic.
Nokia was designed as strongest and most affordable phone, yet you use Iphone that costs 1000$. it's not about how it was designed but whether it addresses your current needs. Developers do not want to manage a cluster of single cpu processes. Not on their laptops and not in the production. And it's not just about management complexity. See this https://github.com/dragonflydb/dragonfly/issues/1229 and it's just one example. Single cpu - is just not enough for today use-cases.
We do not fight off capitalism in any way. Rather, I view capitalism as a powerful engine driving innovation. My experience as an engineer at both Google, a massively profitable entity that contributes significantly to the open source community, and AWS, which effectively utilizes open source software to bolster its own success, has shaped this perspective. I harbor no resentment towards AWS; instead, I see both approaches as legitimate strategies within the scope of a capitalist system. I firmly believe that companies in the open source space need to rise to the challenge of competition and devise effective strategies to thrive in the marketplace.
I think using word "misleading" is also "misleading".
Dragonfly hides complexity. Docker hid complexity of managing cgroups and deploying applications. S3 hid complexity of writing into separate disks. But you do not call S3 or minio misleading because they store stuff similarly to how disk stores files. Dragonfly hides complexity of managing bunch of processes on the same instance and the outcome of this is a cheaper production stack. What do you think has higher effective memory capacity on c6gn.16xlarge: a single process using all the memory or 40 processes which you need to provision independently?
KeyDB implements multiple threading with spin-locks that protect a global shared data structure.
Dragonfly is built upon shared-nothing architecture where each thread manages its own slice of data, hence no need for classical locks and no contention under high load. It still provides atomicity guarantees but allows multiple transactions to progress independently as long as they do not need exlusive access to the same keys. So basically different approaches to the same promise - scale. Also different trade-offs. Shared-nothing approach has less contention and more flexible transaction framework but inhibits a slightly higher 50%th percentile latency (order of 30usec).
It compares a process with a listening port with another process with a listening port. To give another example - nobody compares minio with bunch of disks to which you can write separately, and probably more efficiently.
I made an honest mistake. While I saw DragonflyBSD, I didn't realize its prominence within the BSD community. I assumed that since our project only focuses on Linux, having a similar name in a different "namespace" wasn't a significant issue.
Their goal is to unload the "main" thread from performing i/o related tasks like socket reading and parsing, so it could only spend its precious time on datastore operations. This creates an asymmetrical architecture with I/O threads scaling to any number of CPUs, but the main thread is the only one that touches the hashtable and its entries. It helps a lot in cases where datastore operations are relatively lightweight, like SET/GET with short string values, but its impact will be insignificant for CPU heavy operations like lua EVALs, sorted sets, lists, MGET/MSET etc.