Given the new redis 6 multi io-threads, what is the redis suggested way for optimal performance, when majority of actions are reads?
Until now (redis 5 and below), the common wisdom was to spin up multiple redis instances on the same machine as a slave, ending up with a cascading master/slave structure (https://redislabs.com/ebook/part-2-core-concepts/chapter-4-keeping-data-safe-and-ensuring-performance/4-2-replication/4-2-3-masterslave-chains/)
Given the io-threads, is it better to: - use io-threads OR - keep using multiple, (cascading) redis slave instances per server OR - both?
In the latest redis.conf there is a comment:
Usually threading reads doesn't help much.
Which is what prompted me to ask this question - since this is exactly where the multiple instances per server gains immensely. Or does this mean, that it makes sense to set io-threads for the redis master (writes), but for reads it's better to keep using the multi-instance/cascading slaves model?
Comment From: madolson
Great question! I don't know if anyone has done a deep dive to really figure out the performance differences, but the common wisdom right now is scaling out (adding shards or replicas) is going to give you better performance than adding threads. IO threads is only going to scale to about 3x and will give you lower performance returns than spinning up a separate process. I.E, two threads won't give you 2x performance, but balancing requests between two processes will.
The case where threading can be helpful is if you have a single master that you need to direct traffic too, either for consistent reads or for writes. Then io threads can help you squeeze out a little extra performance out of your one master.
Comment From: kkmuffme
Thanks for the quick reply.
Will be using io-threads for the master only, but for reads I will keep multiple separate redis slave processes.