From a29ed93ad247b9febfea77c6350564d878273ab3 Mon Sep 17 00:00:00 2001 From: Uri Yagelnik Date: Sun, 26 Jan 2025 08:24:34 +0000 Subject: [PATCH 1/4] update I/O threads documentation Signed-off-by: Uri Yagelnik --- topics/benchmark.md | 2 +- topics/encryption.md | 4 ---- topics/latency.md | 18 +++++++++--------- 3 files changed, 10 insertions(+), 14 deletions(-) diff --git a/topics/benchmark.md b/topics/benchmark.md index 46253af4..1c6bed3a 100644 --- a/topics/benchmark.md +++ b/topics/benchmark.md @@ -266,7 +266,7 @@ in account. + Valkey commands return an acknowledgment for all usual commands. Some other data stores do not. Comparing Valkey to stores involving one-way queries is only mildly useful. + Naively iterating on synchronous Valkey commands does not benchmark Valkey itself, but rather measure your network (or IPC) latency and the client library intrinsic latency. To really test Valkey, you need multiple connections (like valkey-benchmark) and/or to use pipelining to aggregate several commands and/or multiple threads or processes. + Valkey is an in-memory data store with some optional persistence options. If you plan to compare it to transactional servers (MySQL, PostgreSQL, etc ...), then you should consider activating AOF and decide on a suitable fsync policy. -+ Valkey is, mostly, a single-threaded server from the POV of commands execution (actually modern versions of Valkey use threads for different things). It is not designed to benefit from multiple CPU cores. People are supposed to launch several Valkey instances to scale out on several cores if needed. It is not really fair to compare one single Valkey instance to a multi-threaded data store. ++ Valkey primarily operates as a single-threaded server from the POV of commands execution. While the server employs asynchronous I/O threads for read/write operations, the core command processing remains sequential. For CPU-intensive workloads requiring multiple cores, users should consider running multiple Valkey instances in parallel. It is not really fair to compare one single Valkey instance to a multi-threaded data store. The `valkey-benchmark` program is a quick and useful way to get some figures and evaluate the performance of a Valkey instance on a given hardware. However, diff --git a/topics/encryption.md b/topics/encryption.md index 085e8666..21d6b446 100644 --- a/topics/encryption.md +++ b/topics/encryption.md @@ -119,7 +119,3 @@ versions, ciphers and cipher suites, etc. Please consult the self documented ### Performance considerations TLS adds a layer to the communication stack with overheads due to writing/reading to/from an SSL connection, encryption/decryption and integrity checks. Consequently, using TLS results in a decrease of the achievable throughput per Valkey instance. - -### Limitations - -I/O threading is currently not supported with TLS. diff --git a/topics/latency.md b/topics/latency.md index 0f6c0156..1046ad56 100644 --- a/topics/latency.md +++ b/topics/latency.md @@ -159,19 +159,19 @@ Only do them if you require them, and if you are familiar with them. Single threaded nature of Valkey ------------------------------- -Valkey uses a *mostly* single threaded design. This means that a single process -serves all the client requests, using a technique called **multiplexing**. -This means that Valkey can serve a single request in every given moment, so -all the requests are served sequentially. This is very similar to how Node.js +Valkey uses a *mostly* single threaded design for command execution. This means that a single process +executes all the client commands sequentially, using a technique called **multiplexing**. +While multiple commands can have their I/O operations processed concurrently in the background, +only one command can be executed at any given moment. This is similar to how Node.js works as well. However, both products are not often perceived as being slow. -This is caused in part by the small amount of time to complete a single request, +This is caused in part by the small amount of time to complete a single command execution, but primarily because these products are designed to not block on system calls, such as reading data from or writing data to a socket. -I said that Valkey is *mostly* single threaded since -we use threads in Valkey in order to perform some slow I/O operations in the -background, mainly related to disk I/O, but this does not change the fact -that Valkey serves all the requests using a single thread. +I said that Valkey is *mostly* single threaded. +We do use threads in Valkey in order to perform I/O operations (including command parsing and I/O operations) +in the background, but this does not change the fact +that Valkey executes all the commands sequentially using a single thread. Latency generated by slow commands ---------------------------------- From 0da6dbcd208381255a77e0869310752622fe8bba Mon Sep 17 00:00:00 2001 From: uriyage <78144248+uriyage@users.noreply.github.com> Date: Wed, 5 Feb 2025 15:00:41 +0200 Subject: [PATCH 2/4] Update topics/benchmark.md Co-authored-by: Madelyn Olson Signed-off-by: uriyage <78144248+uriyage@users.noreply.github.com> Signed-off-by: Uri Yagelnik --- topics/benchmark.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/topics/benchmark.md b/topics/benchmark.md index 1c6bed3a..c0cfcea8 100644 --- a/topics/benchmark.md +++ b/topics/benchmark.md @@ -266,7 +266,7 @@ in account. + Valkey commands return an acknowledgment for all usual commands. Some other data stores do not. Comparing Valkey to stores involving one-way queries is only mildly useful. + Naively iterating on synchronous Valkey commands does not benchmark Valkey itself, but rather measure your network (or IPC) latency and the client library intrinsic latency. To really test Valkey, you need multiple connections (like valkey-benchmark) and/or to use pipelining to aggregate several commands and/or multiple threads or processes. + Valkey is an in-memory data store with some optional persistence options. If you plan to compare it to transactional servers (MySQL, PostgreSQL, etc ...), then you should consider activating AOF and decide on a suitable fsync policy. -+ Valkey primarily operates as a single-threaded server from the POV of commands execution. While the server employs asynchronous I/O threads for read/write operations, the core command processing remains sequential. For CPU-intensive workloads requiring multiple cores, users should consider running multiple Valkey instances in parallel. It is not really fair to compare one single Valkey instance to a multi-threaded data store. ++ Valkey primarily operates as a single-threaded server from the POV of commands execution. While the server can employ threads for I/O operations and command parsing, the core command execution remains sequential. For CPU-intensive workloads requiring multiple cores, users should consider running multiple Valkey instances in parallel. It is not really fair to compare one single Valkey instance to a multi-threaded data store. The `valkey-benchmark` program is a quick and useful way to get some figures and evaluate the performance of a Valkey instance on a given hardware. However, From 07054175b42b0e73fe127b4c70e1bcb7fda6d710 Mon Sep 17 00:00:00 2001 From: uriyage <78144248+uriyage@users.noreply.github.com> Date: Wed, 5 Feb 2025 15:01:08 +0200 Subject: [PATCH 3/4] Update topics/latency.md Co-authored-by: Madelyn Olson Signed-off-by: uriyage <78144248+uriyage@users.noreply.github.com> Signed-off-by: Uri Yagelnik --- topics/latency.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/topics/latency.md b/topics/latency.md index 1046ad56..ca6e5cbe 100644 --- a/topics/latency.md +++ b/topics/latency.md @@ -168,10 +168,6 @@ This is caused in part by the small amount of time to complete a single command but primarily because these products are designed to not block on system calls, such as reading data from or writing data to a socket. -I said that Valkey is *mostly* single threaded. -We do use threads in Valkey in order to perform I/O operations (including command parsing and I/O operations) -in the background, but this does not change the fact -that Valkey executes all the commands sequentially using a single thread. Latency generated by slow commands ---------------------------------- From d3024f9ef448181479525f6ee6f07b3970ad89df Mon Sep 17 00:00:00 2001 From: Uri Yagelnik Date: Wed, 5 Feb 2025 13:03:24 +0000 Subject: [PATCH 4/4] Change title Signed-off-by: Uri Yagelnik --- topics/latency.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/topics/latency.md b/topics/latency.md index ca6e5cbe..158eb45d 100644 --- a/topics/latency.md +++ b/topics/latency.md @@ -156,7 +156,7 @@ as the main event loop. In most situations, these kind of system level optimizations are not needed. Only do them if you require them, and if you are familiar with them. -Single threaded nature of Valkey +Valkey sequential command execution ------------------------------- Valkey uses a *mostly* single threaded design for command execution. This means that a single process