[antirez]

When you are connected to multiple servers the best thing is to have a client that is able to parallelize requests against multiple servers.

There is a trick, (used by some memcached client as far as I know), to do that without multiplexing, that is, usually you should do something like this:

  send GET foo to socket1
  send GET bar to socket2
  replies = some_form_of_multiplexing(socket1,socket2)

Instead since we can observe that usually the round trip time between the peers at socket1 and socket2 are similar, we can do:

   send GET foo socket1
   send GET bar socket2
   reply1 = read(socket1)
   reply2 = read(socket2)

This makes the implementation simpler without making the performances so much worse.

So a good Redis client for a sharded environment should be able to do something like this:

  replies = parallel_queries(["GET","foo"],["GET","bar"],["INCR zap"])

Trying to send the queries to all the servers in parallel and returning the replies ASAP, and in the right order of course.

[salimane]

@antirez, i see what u mean but in this context with "SORT BY GET", in the case of a single server, the command is send to it in one call and the server replies with the result. but in the case of a cluster, the benefit of having the server handle the one call is no more there as of 2.4 at least. the most a good client could actually do is to take the one call "SORT BY GET", recognize it, divide it, do separate calls, merge the results and send them back...which is going back to what were trying to avoid... or is there another way to handle this currently with 2.4?