You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are heavily using rueidisotel and have some flaky latency in our system. We see on the redis server side that request / response times are pretty constant. Now we are investigating where this variance is coming from.
Thus, it would be super useful to have tracing in rueidisotel that would only span across initiating a Do* call and handing the request over to the networking stack on client side. That is, without the entire round trip.
The text was updated successfully, but these errors were encountered:
To log more detailed traces is hard. The only solution I have come up with is injecting hook functions into the ctx and invoking them at the various stages in the pipeline. But I am concerned about its overhead since we need to check if there are hooks in the ctx every time.
Flaky latencies could be caused by several factors, such as huge requests or responses. But mostly the cause could be your CPUs are busy with other things. If you have to make sure your CPUs are underutilized then you could try to increase the PipelineMultiplex option slightly (by 1 or 2) to see if the flaky is relieved.
We are heavily using
rueidisotel
and have some flaky latency in our system. We see on the redis server side that request / response times are pretty constant. Now we are investigating where this variance is coming from.Thus, it would be super useful to have tracing in
rueidisotel
that would only span across initiating aDo*
call and handing the request over to the networking stack on client side. That is, without the entire round trip.The text was updated successfully, but these errors were encountered: