Anecdotal, but it leaves me slightly confused
A multithreaded fork of Redis that is faster
121–130 of 164 posts
Re: A multithreaded fork of Redis that is faster
#122Any time these "much faster than Redis" databases come up, the sysadmin in me wonders how many people have had actual performance limitation issues with Redis. I've seen Redis servers handle hundreds of GB of traffic per hour. I've worked at companies where Aerospike and others are proposed as replacements for Redis because "they're faster" - and I point out the 98% idle CPUs on the Redis server, and the near-100%-us…
As the Sidekiq maintainer, I’ve seen many customers need to shard Redis around 5000-10000 jobs/sec. Sharding is a major operational headache so this could be very useful to heavy job processors if it does prove to scale better. 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 li…
Re: A multithreaded fork of Redis that is faster
#123Any time these "much faster than Redis" databases come up, the sysadmin in me wonders how many people have had actual performance limitation issues with Redis. I've seen Redis servers handle hundreds of GB of traffic per hour. I've worked at companies where Aerospike and others are proposed as replacements for Redis because "they're faster" - and I point out the 98% idle CPUs on the Redis server, and the near-100%-us…
Facebook just published a blog about moving petabytes per hour. I read it, I find the design interesting. I don't need it. But if I do, it's good to know that it's possible, that someone has solved, to have a reference and to possibly use their tool if it's free. So relax, I for one welcome whatever folks are working on out there. If it's true, we can learn from it and apply it in order domains too.
But it's not like that's through one pipe. We don't talk about how many zillions of tons of steel per minute are moved on freeways.
Re: A multithreaded fork of Redis that is faster
#124I'm really curious about the latency metric. I'm running elasticache redis and the round trip average of our Redis get commands is around 1ms. We may have 5-10 in a transaction and look for 10-20ms total time. Anecdotal, but it leaves me slightly confused
Re: A multithreaded fork of Redis that is faster
#125So this year on RedisConf Antirez demoed threaded version for Redis (only transport needs to be multi-threaded, core remains single threaded). Numbers were already amazing. I will pick the community version of Redis any day over forks.
Re: A multithreaded fork of Redis that is faster
#126I'm really curious about the latency metric. I'm running elasticache redis and the round trip average of our Redis get commands is around 1ms. We may have 5-10 in a transaction and look for 10-20ms total time. Anecdotal, but it leaves me slightly confused
Higher traffic loads result in latency increasing. This benchmark covers the maximum load so latency will be much higher.
Re: A multithreaded fork of Redis that is faster
#127Earlier quoted context omitted.
As the Sidekiq maintainer, I’ve seen many customers need to shard Redis around 5000-10000 jobs/sec. Sharding is a major operational headache so this could be very useful to heavy job processors if it does prove to scale better. 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 li…
Ok, what is a job/second?
Re: A multithreaded fork of Redis that is faster
#128Any time these "much faster than Redis" databases come up, the sysadmin in me wonders how many people have had actual performance limitation issues with Redis. I've seen Redis servers handle hundreds of GB of traffic per hour. I've worked at companies where Aerospike and others are proposed as replacements for Redis because "they're faster" - and I point out the 98% idle CPUs on the Redis server, and the near-100%-us…
As the Sidekiq maintainer, I’ve seen many customers need to shard Redis around 5000-10000 jobs/sec. Sharding is a major operational headache so this could be very useful to heavy job processors if it does prove to scale better. 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 li…
Re: A multithreaded fork of Redis that is faster
#129Earlier quoted context omitted.
> ...it's rarely just raw performance. KeyDB has other advantages like multi-threading... What are the advantages of "multi-threading" other than for performance?
Taking advantage of all your cores. Redis is awkward at high capacity since most servers scale CPU with RAM and you'll end up with most cores doing nothing. You can manually run multiple instances on the same server but now they're separate databases with operations and sharding overhead. Multithreading IO also reduces the latency hit from disk-persistence and provides more concurrency and throughput, which is a grea…
That means nothing at all, if performance is not your concern.
Re: A multithreaded fork of Redis that is faster
#130Earlier quoted context omitted.
As the Sidekiq maintainer, I’ve seen many customers need to shard Redis around 5000-10000 jobs/sec. Sharding is a major operational headache so this could be very useful to heavy job processors if it does prove to scale better. 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 li…
May have been better to use GPL2?