Replies: 2 comments 1 reply
-
@yangty89 Thank you. Hopefully we / anyone from the community will be able to work on it. |
Beta Was this translation helpful? Give feedback.
1 reply
-
Redis is single thread single command system. Better to use multiple redis instances with small connection pool |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi, I'am using JMH to test the performance of Jedis under high concurrency (200 concurrent threads). The test is performed on a localhost Redis with a 8-processor CPU. The version of Jedis is 4.1.1 and The Version of Redis is 6.2.6. The test code is shown below:
When I set
poolSize
to 50, I got a QPS of about 70k. However, When I increase thepoolSize
to 200 (which matches the concurrent thread number), the QPS dropped heavily to about only 30k. I've also run aredis-benchmark
with 200 connections, and I got a QPS of about 80k. To find out the reason of performance loss of Jedis with large pool size under high concurrency, I've also tried usingtop -o cpu
to observer the overall CPU usage and the CPU usage of each process. And I got the stats below:I found that Jedis consumes much more CPU time when the connection pool size augments to 200, and, according to the overall CPU usage data, a big portion (about 85%) of CPU time was spent in kernel mode. I wonder if this means that with large connection pool size and under high concurrency, Jedis will make much more socket syscall (write/read) in parallel, and the resulting frequent context switch finally impact the performance heavily? Many thanks!
Beta Was this translation helpful? Give feedback.
All reactions