Hacker News Reader

It seems to me you didn't address the main point from parent: did you benchmark your multithreaded implementation vs a single core Redis? Nevermind the amazing advantages that having to spawn 1 process vs N brings, the question is how does your software compare when Redis is used as inteded.

View on HN

I benchmarked DF vs single core Redis. If there is a constructive suggestion for a different benchmark that compares similar product propositions I will happily oblige and do that. i.e. what do you mean by using Redis as intended?

So two options I am curious about:

- If it's a normal configuration partitioning a single large node with multiple instances using Redis cluster

- A cost equivalent cluster of machines with a similar memory size running on Redis cluster

1. I think this is how Redis the company designed their enterprise solution. You can find architecture documentation on their site. 2. Based on my knowledge it should be more or less equivalent. The reason they put it on the same machine (i am guessing here) is because shards on the same node are behind their Redis proxy, that kinda hides the complexity of connecting to each node separately. it's like a gateway to that machine and to all its redis processes.

Reply on news.ycombinator.com