Connection Management

GLIDE’s API is asynchronous and uses a multiplex connection to interact with Valkey. This means all requests are sent through a single connection as the Rust core takes advantage of Valkey’s pipelining capabilities to improve performance.

Tip

Pipelining is a technique that enhances performance by issuing multiple commands at once without waiting for individual responses.

Using a single connection is the recommended method to optimize performance with Valkey. However, in some scenarios, opening multiple connections can be more beneficial. To open a new connection, a new GLIDE client object should be created, as each GLIDE client maintains a single connection per node.

You should open a new client for the following use cases:

Blocking Commands

Blocking commands, such as BLPOP, block the connection until a condition is met (e.g., the list is not empty for BLPOP). Using a blocking command will prevent all subsequent commands from executing until the block is lifted. Therefore, opening a new client for each blocking command is required to avoid undesired blocking of other commands.

WATCH/UNWATCH Commands

Commands like WATCH, which are used to monitor changes to keys in conjunction with transaction commands, affect the state of the connection. When these commands are executed, they can lead to interactions between threads sharing the same client, since each client utilizes a single multiplexed connection per cluster node. Consequently, threads will share the same connection, and any modifications to its state will impact how subsequent commands are processed. For example, executing WATCH on one thread will cause other threads to watch the same keys, and executing MULTI/EXEC on one thread will UNWATCH the keys for other threads as well. To prevent any issues and ensure the isolation of transactions and watched keys, it is required to create separate clients for these commands.

Reading and Writing Large Values

Valkey has a fairness mechanism to ensure minimal impact on other clients when handling large values. With a multiplex connection, requests are processed sequentially. Thus, large requests can delay the processing of subsequent smaller requests. When dealing with large values or transactions, it is advisable to use a separate client to prevent delays for other requests.