How to use TCP's asynchronous I/O method to communicate with Redis DB pod

[zhaozekunssss]

Hi,

I know there are two ways for Rueidis to connect to Redis now: connection pooling and pipeline mode.

I have a question to ask: Our current requirement is not to use pipeline mode. When using connection pooling mode, if a large number of requests are generated in a short period of time, a large number of TCP connection wires will be created, and send a separate request for each connection wire, which will consume a lot of resources.

Can we communicate directly with the Redis cluster through TCP's asynchronous I/O method? So we only need to create a TCP long connection with each db pod. If possible, how do I need to set it up? If not possible, is there any reason?

[rueian]

Hi @zhaozekunssss, did you disable auto-pipelining (DisableAutoPipelining=true)? Otherwise, rueidis should use pipeline mode automatically.

Or if you like to use pooling mode by default, but sometimes allow pipelining, you can use

cmd := client.B().Get().Key("key").Build().ToPipe()
client.Do(ctx, cmd)

[zhaozekunssss]

Hi @rueian ,
yes, I set DisableAutoPipelining to true(our requirement requires disabling the pipeline mode), and I don't think the pipeline mode is considered TCP asynchronous I/O communication. This solution combines multiple commands and sends them together, right?

I just want to know if there is such a way: If two requests are sent independently, after the first request is sent, the second request does not need to wait for the return of the first request to be sent immediately, and the two requests do not affect each other, then only one TCP connection is enough. Is this feasible? Because I believe TCP communication supports asynchronous communication.

[rueian]

If two requests are sent independently, after the first request is sent, the second request does not need to wait for the return of the first request to be sent immediately, and the two requests do not affect each other, then only one TCP connection is enough. Is this feasible?

This is actually what pipeline mode does. It keeps sending requests without waiting for responses.

This solution combines multiple commands and sends them together, right?

It indeed combines multiple commands and sends them together, but again, it doesn't wait for responses to send the next batch.

[zhaozekunssss]

Thanks for your reply!

I happen to have a question regarding the pipeline mode：

How long will it wait to combine the received commands？We don't want some commands to decrease efficiency by waiting to be combined.This is the reason why we do not choose the pipeline mode.

[rueian]

It doesn’t wait for additional commands to accumulate by default. It only batches the commands that are still pending at the moment it try to send the next batch.