Conversation
|
@itamarhaber PTAL. |
|
Hi. Any update or suggestions for this one? |
|
Heya @2014BDuck - this is on @yossigo's and my plates, sorry for the delay and thanks for the contribution. |
|
Hi. Is there any suggestion for this one ~? Thanks. |
|
Hi. Any feedback for this topic proposal? |
|
@2014BDuck I believe this topic will be very useful but IMHO we can reduce a bit the amount of |
|
@filipecosta90 Thanks! I am going to modify it accordingly asap. |
|
@filipecosta90 @itamarhaber @yossigo |
filipecosta90
left a comment
There was a problem hiding this comment.
@2014BDuck small comments I I believe it's looking very good. Pinging @itamarhaber and @yossigo also.
|
Thanks for pointing it out. I've fixed those placeholder stuffs. ptal @itamarhaber @yossigo @soloestoy ^_^ |
|
@itamarhaber @yossigo Hello, would you mind sending me some feedback so that I could modify this topic accordingly :) |
madolson
left a comment
There was a problem hiding this comment.
Thanks for taking the time to help improve our corpus of documentation! I left some high level comments to try to make it clearer.
| @@ -0,0 +1,119 @@ | |||
| # Threaded I/O | |||
| ## Introduction | |||
| In order to keep it simple and reliable, Redis is mostly single-threaded. The implementation of parallel query execution might set an entry barrier for every new feature. However, there are certain threaded operations such as UNLINK, slow I/O accesses and other things that are performed on side threads. | |||
There was a problem hiding this comment.
| In order to keep it simple and reliable, Redis is mostly single-threaded. The implementation of parallel query execution might set an entry barrier for every new feature. However, there are certain threaded operations such as UNLINK, slow I/O accesses and other things that are performed on side threads. | |
| Redis is implemented as mostly single-threaded application in order to keep it simple and reliable. There are certain threaded operations such as UNLINK, slow I/O accesses and other operations that are performed on side threads that are coordinated by the main thread. |
| ## Introduction | ||
| In order to keep it simple and reliable, Redis is mostly single-threaded. The implementation of parallel query execution might set an entry barrier for every new feature. However, there are certain threaded operations such as UNLINK, slow I/O accesses and other things that are performed on side threads. | ||
|
|
||
| Now it is also possible to handle Redis clients' socket reads and writes in different I/O threads. Since especially writing is so slow, normally Redis users use pipelining in order to speed up the Redis performances per core, and spawn multiple instances in order to scale more. Using I/O threads it is possible to easily speedup two times Redis without resorting to pipelining nor sharding of the instance. |
There was a problem hiding this comment.
Starting with Redis 6.0 and great, it is now possible*
| By default, Redis uses I/O threads on the write system call only. If you want to use it on the read system call, you have to enable this option as well. Usually, threaded reads don't help much. | ||
|
|
||
| ## High-Level Architecture | ||
| The main idea of this feature is to postpone the read and write action and accumulate those events to the next event loop cycle. So that we have multiple events waiting to be handled and use I/O threads to deal with them. |
There was a problem hiding this comment.
I didn't follow this sentence. The high level idea is that IO operations can be done in parallel by making the networking primitives for reading and writing to a client thread safe. So we split the work into identifying the clients with pending operations and then we fan out threads to do it.
|
|
||
|
|
||
| ## Low-Level Design | ||
| ### Where is the pending list |
There was a problem hiding this comment.
My take is that this section is way too detailed. Someone will probably just go read the code if they want to understand this low level of detail. I think if you remove all of the specific implementation details (names of the arguments, functions, etc), and just leave what the algorithm looks like, it will probably be 50% shorter and just as readable.
I would also say you maybe should fold the high-level/low-level design together and just describe the write flow and then the read flow. Although they have some similarities, and you were trying to generalize, they end up being pretty different.
| - n (n >= 2): Use n threads(1 main thread & n-1 I/O threads) to handle network reads/writes. | ||
|
|
||
| ``` | ||
| io-threads-do-reads [yes|no] |
There was a problem hiding this comment.
I would punt the configuration to the end or interleave the configuration with the introduction of the topics. io-threads-do-reads is hard to understand without context.
|
@filipecosta90 is this ok to merge? |
|
2014BDuck seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
|
Close as stale. |
The idea of threaded I/O is mainly about to delay the reads/writes to next aeProcessEvent loop. Working on this topic.