background
During shigenthe internship, I encountered the performance optimization problem of the log system. The optimization point at that time was: use the redis thread pool to achieve performance optimization in the concurrent state. But after looking for a lot of technical solutions, I found that redis thread pool configuration is more troublesome. Coincidentally, this weekend I shigenwas studying spring boot+ bitmapthe function of implementing sign-in. This problem appeared in front of me again. I can't get used to it. I studied the redis thread pool again.
First of all, let me go back to the working principle of the thread pool, which shigenis also mentioned in the article "High Performance API Design".
configuration
Due to space limitations and beautiful typesetting requirements, multi-line codes are displayed in the form of code screenshots.
shigenWhen typesetting, the "image adaptive" option is selected, which means that the horizontal and vertical screens have the same effect!
rely
Select jedis as the client of redis. So the required dependencies are:
Therefore, the core dependency is that jedis commons-pool2it should be noted that it is sring-boot-starter-redisexcluded in letture-core.
configuration file
It is mainly to configure the parameters of the thread pool. The data here is for the obvious effect of the test. The specific configuration parameters can be obtained through pressure testing.
spring:
application:
name: redis-springboot
# 配置redis的信息
redis:
host: 127.0.0.1
database: 0
timeout: 1200
password: 123456
jedis:
pool:
# 最大连接数
max-active: 10
# 最大阻塞等待时间
max-wait: -1
# 最大空闲连接
max-idle: 4
# 最小空闲连接
min-idle: 2
configuration class
This is the core.
This is mainly to configure jedis jedisConnectionFactoryand the serialization method of redis, because if you are not careful, the stored data will be garbled. Of course, information such as link address, port, and password can be obtained from the configuration file, which is simply shown here.
Everything is in place, now it's just a matter of testing.
test
I wrote one testControllerto test the effect of the implementation.
The main operation here is to generate a UUID as the value whose key is "name", and then read the value and return it. It seems very simple, but the next hard core is coming.
ab -c 10 -n 1000 127.0.0.1:9000/redis
This command is for stress testing, using 10 concurrent threads to request 1000 interfaces in total. First look at the output of the console:
This is a stress test report, which shows that 0.293s1000 requests have been completed now, but I have 10 concurrent requests, so the connection pool should be up now.
At this time, redis monitoring shows 9 connections, OK, count, redis-cli is connected to one, the maximum number of connections configured by the project is 10, and the minimum is 2 free. My request is over, and there are still 8 connections. It proves that the connection pool configuration of redis is successful, and the performance has been optimized a lot.
The above is Shigen's technology sharing today. If you think it is good, think 点赞 关注 转发 在看it. Your support is the motivation for me to keep updating.
Together shigen, every day is different!