What does the io-threads configuration option introduced in Redis 6.0 actually parallelize, what does it deliberately not parallelize, and when is turning it on justified?

## The problem io-threads was built for On a busy Redis instance serving simple commands, the main thread often spends more time moving bytes than doing keyspace work. A `GET` that returns a 20 KB value costs a hash lookup (nanoseconds) plus a `write()` of 20 KB plus protocol encoding (microseconds). Profiling such instances showed the event loop dominated by socket syscalls, `memcpy`, and RESP parsing/serialization - work that is *embarrassingly parallel* because each client's bytes are independent. ## What Redis 6.0 did `io-threads N` starts N-1 additional threads (the main thread counts as one of the N). The flow becomes: 1. The main thread collects the set of clients with pending reads or pending writes. 2. It **partitions that list round-robin across the io-threads**, then signals them. 3. Each io-thread performs its clients' `read()` (and RESP parsing into command structures) or reply encoding and `write()`. 4. The main thread waits for all io-threads to finish the batch (a spin/barrier), then **executes the parsed commands itself, serially**. That last step is the crux: the io-threads never touch the keyspace. There is no locking added anywhere, because no shared data structure is mutated concurrently. Command order is still whatever the main thread decides, replication is still a single ordered stream, and every command and script remains atomic. ## Configuration and defaults ``` io-threads 1 # default: disabled (main thread only) io-threads-do-reads no # default: offload writes only ``` By default, even with `io-threads` set, only *writes* (reply encoding + `write()`) are offloaded. Reads and parsing move off only with `io-threads-do-reads yes`, which historically gave a smaller and more workload-dependent benefit. `io-threads` cannot be changed at runtime in a meaningful way on older versions - treat it as a restart-level config and verify on your build. ## When it actually helps Enable it only after measuring. The signature of an I/O-bound instance is: high ops/sec or high bytes/sec, main thread at ~100% CPU, but `SLOWLOG` empty and command complexity low - i.e. the CPU is not going into command execution. Large values (kilobytes, not bytes) amplify the effect because encoding and copying scale with payload size. Concretely it is justified when: - Throughput is capped and the box has idle cores. - Values are large, or the client count and connection churn are high. - Commands are O(1) - the work is genuinely in the pipes. Redis's guidance is to set `io-threads` to fewer than the number of cores (leaving headroom for the OS, `bio` threads, and any forked child), and typically not above ~8, since coordination overhead grows. ## When it does nothing, or hurts - **CPU-bound commands.** If your latency comes from `SORT`, big `LRANGE`s, `ZRANGEBYSCORE` over huge ranges, or Lua, io-threads cannot help - that work is on the main thread by design. - **Low throughput.** The batching barrier costs a spin per iteration; on a lightly loaded instance you pay overhead for nothing and can see slightly worse latency. - **Small values and pipelining already in use.** Pipelining amortizes syscalls, which is the same win from a different direction, and is usually the cheaper fix. ## What to say about "Redis is multi-threaded now" The honest framing: Redis parallelized **I/O**, not **execution**. Redis 6.0 introduced io-threads; later Redis and Valkey releases have refined the same idea - deeper async I/O, better thread affinity - but on a given shard, commands still execute one at a time. Anyone claiming that raising `io-threads` multiplies command throughput on CPU-bound workloads is wrong. The alternative for CPU-bound scaling remains what it always was: shard the keyspace across more instances (Redis Cluster or multiple instances per host), each with its own event loop and its own core. ## Operational cautions io-threads spin while waiting for work in some versions, so CPU accounting can look alarmingly high even when idle - pin and size accordingly, and never allocate more io-threads than free cores, or you will contend with the main thread and make latency worse than the baseline you were trying to fix.