Connection Management
GLIDE is an asynchronous client and uses a multiplex connection to interact with Valkey, taking advantage of Valkey’s pipelining capabilities to improve performance.
This guide will go over how to manage your GLIDE clients for optimal performance.
Connection Pooling
Section titled “Connection Pooling”If you are coming from other Valkey or Redis clients (such as Jedis, redis-py, or go-redis), you may expect a connection pool approach. GLIDE handles this differently.
For most workloads, use a single GLIDE client instance for the best performance.
GLIDE leverages Valkey’s pipelining capabilities to efficiently handle large amounts of requests, even from multiple threads, using a single connection. For more on GLIDE’s multiplex architecture, take a look at Asynchronous Execution.
When to Use Multiple Clients
Section titled “When to Use Multiple Clients”Due to the multiplex design, a single connection becomes a bottleneck when executing commands that can block the connection. Currently, it is recommended to use separate clients in these situations.
Be aware that in cluster mode, GLIDE maintains a connection to each node in the cluster; it is not scalable to open a large number of clients.
Reading and Writing Large Values
Section titled “Reading and Writing Large Values”GLIDE’s multiplex connection means that 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.
Blocking Commands
Section titled “Blocking Commands”Opening a new client for each blocking command is recommended to avoid blocking the connection.
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 on the pipeline from executing until the block is lifted.
Pub/Sub Commands
Section titled “Pub/Sub Commands”High-throughput Pub/Sub workloads can decrease overall throughput on a shared connection. Consider using a dedicated client for Pub/Sub for the best performance.
For more details on configuring Pub/Sub with GLIDE, see Pub/Sub Messaging.
WATCH/UNWATCH Commands
Section titled “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.