I still remember the firs time I was exposed to redis and how surprising it was that it could only use one CPU. I think we had 4 core servers at the time and I had to remind everyone that 25% cpu usage was maxed out.
But still, redis on machines of that era (2011) easily saturated our 1gbps nics.
Today on AWS I see elasticache instances saturate their 10gbps interfaces. But it does seem like such a waste that you can provision up to a 96 vCPU instance of elasticache redis and leave so much CPU unusable.
I also find it interesting that the BSD license enables this 3rd party company to fork Redis and build closed source commercial software on top of it. One of the trade offs to consider when licensing a project.
This is the best part of BSD licensed software. Everyone gets a level foundation. They can do what they want with the code. Nobody has an advantage over anyone else.
It can be the worst part for many. The author loses any leverage to recoup for their labor. You can blame the engineer for picking an inappropriate license but much OSS is written by folks in their 20s: plenty of time for programming, little life experience with law.
And yes, I’ve talked privately with many people in this exact situation.
I compiled keydb on my local machine. Testing it out with sidekiq and seems to at least work as expected. As far as any improvement vs vanilla redis, I would have to throw a lot more work at it.
If you have the Sidekiq repo cloned, you can try bundle exec bin/sidekiqload. It’s a mostly self-contained script that runs 100,000 jobs, takes about 10-20 sec on my laptop, edit lightly as necessary.
Using ruby 2.5.3p105 and current sidekiq master, five runs of sidekiqload on vanilla redis took an average of 13.0167407516 sec. For KeyDB, average of 5 runs took 12.8944184326 sec, so an improvement but not really a whole lot.
Not surprising. On Ruby 2.6.3, I still see Redis at 25% CPU and Ruby at 100%. We’d need to run a much larger, multi-process, multi-machine load test to get realistic production results.
I still remember the firs time I was exposed to redis and how surprising it was that it could only use one CPU. I think we had 4 core servers at the time and I had to remind everyone that 25% cpu usage was maxed out.
But still, redis on machines of that era (2011) easily saturated our 1gbps nics.
Today on AWS I see elasticache instances saturate their 10gbps interfaces. But it does seem like such a waste that you can provision up to a 96 vCPU instance of elasticache redis and leave so much CPU unusable.
Mike: Saw your comment about this on the hackernews thread: https://news.ycombinator.com/item?id=21186825
Have you actually done any benchmarks with this and sidekiq?
This is the best part of BSD licensed software. Everyone gets a level foundation. They can do what they want with the code. Nobody has an advantage over anyone else.
It can be the worst part for many. The author loses any leverage to recoup for their labor. You can blame the engineer for picking an inappropriate license but much OSS is written by folks in their 20s: plenty of time for programming, little life experience with law.
And yes, I’ve talked privately with many people in this exact situation.
Sorry, but none of the developers in the BSD projects feel this way. We get code back all the time, too.
Ok, you’ve talked to those who like it. I’ve talked to those who consider it a mistake. Both things can be true.
Nope, I have no idea if it will work and how fast.
I compiled keydb on my local machine. Testing it out with sidekiq and seems to at least work as expected. As far as any improvement vs vanilla redis, I would have to throw a lot more work at it.
If you have the Sidekiq repo cloned, you can try
bundle exec bin/sidekiqload. It’s a mostly self-contained script that runs 100,000 jobs, takes about 10-20 sec on my laptop, edit lightly as necessary.Using ruby 2.5.3p105 and current sidekiq master, five runs of
sidekiqloadon vanilla redis took an average of 13.0167407516 sec. For KeyDB, average of 5 runs took 12.8944184326 sec, so an improvement but not really a whole lot.Not surprising. On Ruby 2.6.3, I still see Redis at 25% CPU and Ruby at 100%. We’d need to run a much larger, multi-process, multi-machine load test to get realistic production results.