A multithreaded fork of Redis that is faster • Hacker News Board

Re: A multithreaded fork of Redis that is faster

#31

Post by wolco » Mon, Oct 07, 2019, 6:20 PM UTC

penagwin wrote: post #9

bengotow wrote: post #3

Earlier quoted context omitted.

Same! I'd also be curious to hear about production scenarios that would really benefit from Redis going 5x faster. It's pretty darn fast to start with!

At my job we're currently re-building our website in django, and we make heavy use of redis caching. Our website is definitely not "high traffic" but we get somewhere around 300,000 requests a day, mostly concentrated around business hours (We're a local clothing wholesaler). I haven't tested it under production loads, but just swapping our redis for keydb (THANKS DOCKER!) I saw no improvement in my artificial load t…

You would probably need 30,000 million a day but then other parts of your setup would fail. Redis being the bottleneck is an unusual case.

Re: A multithreaded fork of Redis that is faster

#32

Post by avar » Mon, Oct 07, 2019, 6:21 PM UTC

nicolaslem wrote: post #10

moab wrote: post #6

Earlier quoted context omitted.

Can you elaborate on why? As someone who works on parallel/concurrent algorithms and data structures a single-threaded system design seems anathema to most research over the past decade (maybe excluding H-Store, which uses local single-threadedness in an interesting way).

Not parent but the single threaded approach really shines when executing Lua scripts in Redis. Except for some very specific edge cases, the execution of a script is atomic and since no command is ever processed concurrently you can rule out data races. I am sure it would be possible to provide these guaranties while offering concurrent execution but most likely at the expense of a simple design.

It shines right up until the moment someone writes a Lua command that takes more than a trivial amount of time, now your entire server is blocked in a pile-up of connections waiting on some relatively trivial amount of code being executed.

Re: A multithreaded fork of Redis that is faster

#33

Post by gok » Mon, Oct 07, 2019, 6:34 PM UTC

On 32 cores? Doesn't seem like particularly great scaling.

Re: A multithreaded fork of Redis that is faster

#34

Post by gtirloni » Mon, Oct 07, 2019, 6:35 PM UTC

not_a_cop75 wrote: post #30

kirstenbirgit wrote: post #28

Earlier quoted context omitted.

It works, it's simple, and it's battle tested.

Does anyone not read into the sarcasm? This is the same cliche format stating that x is better than y, in such a manner to supposedly shame people still using y.

Nobody is shaming anyone.

Re: A multithreaded fork of Redis that is faster

#35

Post by azhng » Mon, Oct 07, 2019, 6:36 PM UTC

manigandham wrote: post #23

erulabs wrote: post #20

Any 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…

True, it's rarely just raw performance. KeyDB has other advantages like multi-threading and disk-based persistence (instead of being limited by RAM) that makes it better at utilizing your server resources and handling larger scales.

But isn't the point of Redis is to be used as a caching layer instead of persistent layer

Re: A multithreaded fork of Redis that is faster

#36

Post by t0mbstone » Mon, Oct 07, 2019, 6:39 PM UTC

azhng wrote: post #35

manigandham wrote: post #23

Earlier quoted context omitted.

True, it's rarely just raw performance. KeyDB has other advantages like multi-threading and disk-based persistence (instead of being limited by RAM) that makes it better at utilizing your server resources and handling larger scales.

But isn't the point of Redis is to be used as a caching layer instead of persistent layer

But what if you could have the speed of RAM-based storage, and still have persistence? Sounds pretty appealing to me, personally.

Re: A multithreaded fork of Redis that is faster

#37

Post by acroback » Mon, Oct 07, 2019, 6:42 PM UTC

tengbretson wrote: post #4

I've always considered the single-threaded nature of Redis to be one of its greatest features.

Oh... Tell me more why being not multithreaded is a failure for Redis?

Re: A multithreaded fork of Redis that is faster

#38

Post by BubRoss » Mon, Oct 07, 2019, 6:42 PM UTC

erulabs wrote: post #20

Any 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…

If redis isn't multi-threaded the more cores and threads you have, the less CPU usage the machine would show, even if Redis is being stressed.

Re: A multithreaded fork of Redis that is faster

#39

Post by vimota » Mon, Oct 07, 2019, 6:44 PM UTC

erulabs wrote: post #20

Any 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…

The ability to scale vertically instead of sharding is a very nice sysadmin feature that although isn't solving "must faster than redis" is related to it due to multi-threading.

Re: A multithreaded fork of Redis that is faster

#40

Post by sciurus » Mon, Oct 07, 2019, 6:52 PM UTC

nitwit005 wrote: post #22

moab wrote: post #6

Earlier quoted context omitted.

Can you elaborate on why? As someone who works on parallel/concurrent algorithms and data structures a single-threaded system design seems anathema to most research over the past decade (maybe excluding H-Store, which uses local single-threadedness in an interesting way).

You can run multiple instances of redis on the same machine, which gets you parallelism from multiple processes instead of multiple threads. There's some extra deployment effort in doing so, but it's not generally a big issue. It also isn't exactly single threaded. It calls fork when it wants to persist data to disk, which is functionally similar to starting up a thread to do disk IO.

Going from a single processes holding all your data to having your data sharded across multiple processes can be more than a little effort.

Also, it might now have any benefit for you. Imagine a certain key is particularly hot. Having one multithreaded redis process handling access to it might speed things up. Running multiple sharded redis processes won't, since only one of them will have that key.