Feature: `ContextTimeoutEnabled`
proost opened this issue · comments
syncDo
and syncDoMulti
in pipe
can close connection when i/o timeout happens.
when architecture looks like below:
client -- server -- redis
client set timeout to requests. timeout which is set by client can be various(sometime too short) and it can hurt performance on redis and server. because making a new connection is expensive operation both server and redis.
so we need to ContextTimeoutEnabled
features like go-redis already did.
If ContextTimeoutEnabled
is true, we only respect ConnectionWriteTimeout
. Only using ConnectionWriteTimeout
, we can satisfy SLO and performance both.
I don't really like the idea of having a toggle to ignore context timeout globally. Say you first ignore context timeout globally, but later you find you need timeout in some cases, then you have no choice but to flip the toggle again.
Furthermore, syncDo
and syncDoMulti
could be seldom used if the server serves concurrent requests from clients. Once concurrent requests are detected, rueidis will start pipelining and not use syncDo
and syncDoMulti
anymore. When pipelining, a connection will not be closed if context timeout is reached.
If the server wants to ignore context timeout, it can pass the context with context.WithoutCancel()
.
If the server wants to keep connections if timeout, it can set AlwaysPipelining: true
.
Okay, I understood. I Figured out this idea is bad.