Possibility of optimizing the command expiring mechanism

[yangty89]

Hi @mp911de, while doing performance tests on Lettuce (using one single shared connection), I found from the frame graph of client thread that the io.lettuce.core.protocol.CommandExpiryWriter#potentiallyExpire method consumes a relatively large portion of time (about 8%). It seems that it's caused by the context switch incurred when we add the command expiring task to the LinkedBlockingQueue of DefaultEventExecutor. If I simply set the timeout to zero on RedisClient to disable the expiring task, I will get a performance gain of about 30% (from 65k ops to 85k ops). So I think maybe we could try using some other command expiring approaches, perhaps a HashedWheelTimer, instead of the LinkedBlockingQueue, to see if it will bring some positive impact on performance :)

[mp911de]

Nothing comes for free. Expiring a task requires scheduling of a task that completes the command with an exception. Happy to accept a pull request that improves performance behavior. The expiration timeout begins with the command invocation before the command is sent to the server.

[yangty89]

@mp911de Thanks for reply! I will do some benchmarking on the HashedWheelTimer approach and make a pull request if it improves the performance of expiring task scheduling :)

Also I'm thinking about the possibility of using a set of connections (not a connection pool, size of connection set may be the number of processors), instead of one single shared connection, to fully exploit the concurrency capacity of multi-processors machines. Here is the discussion and benchmarking post months ago, I think maybe we could take a further look at it :)