Need some help identifying lettuce performance issue.

[y2241]

During our load testings, we notice that when our ec2 instances are busy (cpu utilization is close to 100%), the lettuce latency metrics based on CommandLatencyEvent shows slowness. For example, a simple get command could take 100ms, while on redis server side it only takes about 10ms.
When the ec2 instances are not busy, then all the redis commands are fast on client side.
We have captured the thread profiles (using new relic thread profiler) for both busy and non-busy scenarios. When it is busy, the profile shows non-0%. We have many other asynchronous services such as Async apache http client thread pool, etc which are also using the ForkJoin.commonPool and our ec2 instance is pretty small. See attached file.

Do you have any suggestion on how to improve our performance? Is there a way to use a non-default threadpool in lettuce client config? Any suggestion which could improve our performance is greatly appreciated. (we are using 6.2)

[mp911de]

FutureSyncInvocationHandler is only used when you use the synchronous API. In that case, the thread will be blocked until the command has succeeded. This has nothing to do with a ForkJoinPool, but it is the Java utility used to park the thread.

If you want to avoid thread blocking, then use the async API consistently.

[y2241]

Thanks, what you said explains what we saw.
However, we did try connection.async(). The performance (the average time used for each redis command) is actually worse than connection.sync(). But we are using single LettuceClient and single connection from that client in each jvm, so maybe that is why the connection.async() does not work well?

The reason why we use single connection instead of pooled connections was that we had load tests done before and the pooled connections did not improve performance. Maybe we did not implement it properly.
Is there good document or sample codes that I can read on how to properly implement async command or redis connection pooling?