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 have multiple redis context connecting to different redis clusters, and both contexts will be running in seperate threads and will be passed in redisClusterAppendCommand and redisClusterGetReply function. Do you think there will be any issues? Is there any shared variable which can cause problem in above function call?
Reason i am saying is, we did some load test and we believe that our latency is getting affected. To explain in more detail, earlier we just had single context. It has suppose latency X for redisClusterAppendCommand and latency Y for redisClusterGetReply. Now we have one more redis context, and we called above functions and we saw for old redis context latency for redisClusterAppendCommand increased from X to Some X+T and for redisClusterGetReply from Y to Y+T`.
Technically i am asking two questions:
In serialise call to above two functions for two different redis context, is it supported? Should we expect increase in latency for our original context for above function calls?
In parallel calls to above function with two different redis context, is there any shared variable which can cause issues while calling above two functions?
The text was updated successfully, but these errors were encountered:
Interesting. I don't think the latency for individual calls to the blocking API should increase if you have different contexts and run them in the same thread. The redisClusterAppendCommand() command just adds the commands to an internal queue in hiredis and redisClusterGetReply() triggers the socket send and wait for a reply.
To avoid this serial send+wait on multiple contexts you might want to look into the async-API option, i.e. use an eventloop running on a single thread and use hiredis-clusters async-API. You can find examples here and here.
This setup gives you the parallell behaviour on a single thread (you can send commands via different contexts and then "wait" for responses in parallell).
Since hiredis-cluster uses hiredis, which is not stated to be threadsafe, its not supported. I believe it would work if you pin a context to a thread, and I believe there are users that run it like that.
We have multiple redis context connecting to different redis clusters, and both contexts will be running in seperate threads and will be passed in redisClusterAppendCommand and redisClusterGetReply function. Do you think there will be any issues? Is there any shared variable which can cause problem in above function call?
Reason i am saying is, we did some load test and we believe that our latency is getting affected. To explain in more detail, earlier we just had single context. It has suppose latency X for redisClusterAppendCommand and latency Y for redisClusterGetReply. Now we have one more redis context, and we called above functions and we saw for old redis context latency for redisClusterAppendCommand increased from X to Some X+T and for redisClusterGetReply from Y to Y+T`.
Technically i am asking two questions:
The text was updated successfully, but these errors were encountered: