why dispatch() can lead to performance degradation

[Sinbol]

The reason is that I wanted to define a customize command, but found that the performance of dispatch() is relatively poor.

test case as following:
I tried to call sync.set() 100 times to write data to redis and record the use time, i then called the same setcommand but using sync.dispath() to write same data, found that the time consumption nearly doubled.

    sync.set(key，value);

vs

    sync.dispatch(io.lettuce.core.protocol.CommandType.SET,new StatusOutput<>(codec), new CommandArgs<>(codec).add().addValue()

this gap has exceeded my understanding, wonder the reason...
hope get help and kindly explain the difference.

[tishun]

Hey @Sinbol ,

Can you share the way you are making this benchmark?

Both cases use (eventually) the same dispatch method.
I also attempted to reproduce your measurements but I could not see an overwhelming improvement y using any of the methods.

[tishun]

One note - there is a performance hit on the first command(s) being sent (did not delve deeper why, but I assume it is the penalty of establishing a connection, especially in the cluster scenario). In order to avoid this skewing your measurements I would recommend sending a one or more commands before starting the measurements.

[Sinbol]

I'm sorry for the delayed response. First thank you for your answer. And recently I have spent some more time researching the issue, and it seems that I have found the answer. The problem lies in the add() method. It seems that the parameter passed to add() cannot be treated as a key, so the correct node is not calculated before sending the command. As a result, the request triggers a move response in some nodes, and Lettuce retrieves the correct execution node from the move information. Obviously, this leads to a performance degradation. I have confirmed this issue by capturing packets. addKey() should be used here to solve the problem. Thank you for your attention again!

[tishun]

Thanks for digging into this. I suppose I did not have the exact same code when testing.
Glad you were able to find the culprit yourself!