Replies: 2 comments 1 reply
-
Generally speaking, a connection count above the number of CPU cores is going to impose overhead. You already experienced an increase in throughput when reducing the connection count to 8. Lettuce connections are threadsafe and you do not need pooling unless you're using transactions or blocking commands. |
Beta Was this translation helpful? Give feedback.
-
Hi @mp911de, I've done a detailed benchmarking comparing the performance of Jedis and Lettuce, in different mode. And I found that we got the highest score when using a list of Lettuce connections to serve requests under high concurrency. The scores is shown below. I think maybe we could introduce this mode in Lettuce :) |
Beta Was this translation helpful? Give feedback.
-
Hi, I'am using JMH to test the performance of Lettuce under high concurrency (200 concurrent threads). The test is performed on a localhost Redis with a 8-processor CPU. The version of Lettuce is 6.1.6 and The Version of Redis is 6.2.6.
I found that Lettuce performs well within a single shared connection - I got a QPS of about 60k. But the performance drops slightly when I use a connection pool of 100 connection - I got a QPS of about 40k. I think it's reasonable because when it comes to connection pooling, although we may take advantage of a multi-processor CPU to send requests on parallel, howerver, threads should obtain the connection first before sending a request, and the connection occupied by a thread could be released only when the thread has received the response from Redis. This differs a lot from single shared connection mode, in which all the threads could send requests to the single connection at same time. And from the view of Redis, it's some kind of pipelining, which has a positive impact on performance.
However, given that a Lettuce connection is thread safe for most Redis commands (blocking commands should be processed in dedicated connections), and Lettuce will dispose netty EventLoops according to CPU processor number, I think we may have a kind of "unsafe" connection pool - for example perhaps just a List of Lettuce connections, and let the thread choose randomly a connection for sending normal Redis requests. Thus we may take advantage of both multi-processor CPU and redis pipelining. I have made a test for this idea using 8 connections, and I got a QPS of about 100k, which is nearly double the score I got for single thread mode and connection pooling mode :)
Beta Was this translation helpful? Give feedback.
All reactions