Jedis is the official Java client of Redis and features convenient use and excellent performance. For details, see Jedis Documents.
Proper configurations of Jedis connection pool parameters effectively improve the performance of clients using Redis. This section provides suggestions on how to use Jedis and configure the parameters of the connection pool.
Configuration Methods
The following shows how to configure Maven dependencies using Jedis 4.3.1:
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>4.3.1</version>
</dependency>
Jedis uses Apache Commons-pool2 to manage connection pools. GenericObjectPoolConfig is an important parameter for defining JedisPool. The following is a use example of GenericObjectPoolConfig.
GenericObjectPoolConfig<Jedis> config = new GenericObjectPoolConfig<>();
config.setMaxTotal(100);
config.setMaxIdle(50);
config.setMinIdle(5);
config.setTestWhileIdle(true);
....
Initializing Jedis:
JedisPool pool = new JedisPool(config, host, port, timeout, password);//Create a connection pool.
try (Jedis jedis = pool.getResource()) { //Obtain a connection and release the connection automatically after execution.
//Run commands on the Jedis client.
} catch (Exception e) {
e.printStackTrace();
}
pool.close();//Close the connection pool.
Parameter Description
A Jedis connection is a resource managed by JedisPool in the connection pool. JedisPool ensures the connections are in a manageable range and the threads are secure. Proper configurations of GenericObjectPoolConfig improve Redis service performance and reduce resource overhead. The following tables introduce some of the important parameters and provide configuration suggestions.
Table 1. Description about GenericObjectPoolConfig
Parameter | Description | Default Value | Suggested |
maxTotal | Maximum number of connections in a connection pool | 8 | Refer to the following section of Parameter Configuration Suggestions. |
maxIdle | Maximum number of idle connections in a connection pool | 8 | Refer to the following section of Parameter Configuration Suggestions. |
minIdle | Ensure minimal idle connections, and create new connections if idle connections are insufficient. | 0 | Refer to the following section of Parameter Configuration Suggestions. |
blockWhenExhausted | Indicates whether the process to obtain new connections will be blocked and be waiting when the connections are exhausted. l true: The process is blocked until a new connection is obtained or maxWaitMillis times out. An exception occurs. l false: An exception occurs directly.
| true | Default Value |
maxWaitMillis | Maximum waiting time for obtaining a connection when connections are exhausted, in milliseconds. -1 indicates that it is always blocked. | -1 | Set a proper timeout duration so that applications will not be blocked or do not respond when the connections are exhausted. |
testOnBorrow | Indicates whether to check the connection validity using the ping command when obtaining connections from the connection pool. Invalid connections will be removed. | false | You are advised to use the default value. If this parameter is set to true, a ping command is sent before each command is executed, affecting the performance of large applications with a large number of concurrent requests. Set this parameter to true to provide valid connections in scenarios with high service availability requirements.
|
testOnReturn | Indicates whether to check the connection validity using the ping command when returning connections to the connection pool. Invalid connections will be removed. | false | You are advised to use the default value. If this parameter is set to true, a ping command is sent after each command is executed, affecting the performance of large applications with a large number of concurrent requests. |
lifo | Indicates whether LIFO is used to manage connections. l true: Last in First Out (LIFO) l false: First in First Out (FIFO) | true | You are advised to use the default value. |
fairness | Indicates whether to obtain connections from the connection pool in the order of concurrency. | false | You are advised to use the default value. The performance is better if you select false. |
jmxEnabled | Indicates whether to enable jmx monitoring. | true | You are advised to use the default value and enable jmx monitoring on the application. |
testWhileIdle | Indicates whether to monitor the validity of idle connections. Invalid connections will be released. It is valid only when timeBetweenEvictionRunsMillis > 0. | false | You are advised to set it to true. You can also use JedisPoolConfig. |
timeBetweenEvictionRunsMillis | Interval for detecting idle connections, in milliseconds. -1 indicates that idle connections are not detected. | -1 | You are advised to enable detection of idle connections. You can set the interval based on your requirements. You can also use JedisPoolConfig. |
minEvictableIdleTimeMillis | Idle connection eviction time, in milliseconds. If a connection is not used for a period longer than this parameter, it will be released. -1 indicates that idle connections are not released. It is valid only when timeBetweenEvictionRunsMillis > 0. | 1800000 milliseconds (30 minutes)
| You can configure the parameter as required. It is recommended to use the default value. You can also use the configurations of JedisPoolConfig. |
numTestsPerEvictionRun | Indicates the number of idle connections detected. If the value is -n, it indicates that 1/n connections are detected. | 3 | You can configure the parameter as required. |
You can also refer to JedisPoolConfig on the official website of Jedis. jedis and spring data redis are the default JedisPoolConfig classes used by SDK. JedisPoolConfig classes are inherited from GenericKeyedObjectPoolConfig classes. JedisPoolConfig sets some parameters in the constructor to be more user-friendly:
public class JedisPoolConfig extends GenericObjectPoolConfig<Jedis> {
public JedisPoolConfig() {
// defaults to make your life with connection pool easier :)
setTestWhileIdle(true);
setMinEvictableIdleTime(Duration.ofMillis(60000));
setTimeBetweenEvictionRuns(Duration.ofMillis(30000));
setNumTestsPerEvictionRun(-1);
}
}
A JedisPool connection pool has a maximum of eight idle connections by default. After idle connection detection is turned on, a ping command is sent to check the validity of connections and idle connections are detected every 30s. If a connection is idle or unused for 60s or invalid (abnormal connection), it will be released. Only one connection is released at a time.
Recommendations on Parameter Settings
Relationship Between maxTotal, maxIdle and minIdle
maxTotal indicates the capacity of a connection pool, including idle connections and connections in use. When a connection is returned to the connection pool, it will be released directly if the number of idle connections exceeds maxIdle. A connection pool must have the minimum number (minIdle) of connections, and new connections will be added if idle connections are insufficient.
maxTotal
To set a proper value for maxTotal, take note of the following factors:
l The required concurrent connections based on your business requirements.
l The amount of time that is required to run the command.
l The limit of Redis connections. For example, if you multiply the value of maxTotal by the number of connections on a client, the resulting value must be smaller than the maximum number of connections supported by Redis.
l The amount of resources that are consumed to create and release connections. If the number of connections that are created and released for a request is large, the processes that are run to create and release connections are adversely affected.
For example, the average time that is consumed to run a command, including the time to obtain connections or send requests and respond with network overhead, is approximately 1 ms. The queries per second (QPS) of a connection is about 1,000, which is calculated by dividing 1 second by 1 millisecond. The expected QPS of an individual Redis instance is 10,000. The theoretically required size of a connection pool (maxTotal) is 10, which is calculated by dividing 10,000 by 1,000.
However, this is only a theoretical value. The actual operating conditions and business pressures are changing dynamically. It is also essential to reserve more TPS to account for unpredicted demands. For Redis servers that have a high QPS, if a large number of commands are blocked, the issue cannot be resolved even with a large resource pool.
maxIdle and minIdle
maxIdle and minIdle are used to control the upper and lower limits of the number of available connections.
A connection pool achieves its best performance when the maxTotal value is equal to the maxIdle value. This way, the performance is not affected by the scaling of the connection pool. We recommend that you set the maxIdle and minIdle parameters to the same value if your business traffic fluctuates greatly. If the number of requests is small, the connection resources are wasted.
You can evaluate the size of the connection pool used by each node based on the actual total QPS and the number of clients that Redis serves.
Obtaining Proper Values Based on Monitoring Data
In actual scenarios, a more reliable method is to try to obtain optimal parameter values based on monitoring data. You can use JMX or other monitoring tools to find proper values.