Thanks for the answer. I hadn't realised requests were made in parallel, I first noticed it when multiget's took linear time in machines with high loads. Looking at the code led me to the previous conclusion (N gets for multiget for N keys). I agree it would take a major overhaul of the code to change the current behaviour, possiby more than it's worth for the potencial gains.
2011/11/4 Sylvain Lebresne <sylv...@datastax.com>: > 2011/11/4 Filipe Gonçalves <the.wa.syndr...@gmail.com>: >> Multiget slice queries seem to fetch rows sequentially, at least >> fromwhat I understood of the sources. This means the node that >> receives amultiget of N keys does N get operations to the other nodes >> in thecluster to fetch the remaining keys. >> Am I right? Is this the way multiget works internally? > > The 'sequentially' is probably not right depending on what you meant > by that (see below) but otherwise yes, a multiget of N keys is internally > splitted into N gets. > >> Also, shouldn't this be done in parallel, to avoid contacting >> nodesmore than once? > > It's done in parallel, in that the coordinating nodes send all the get > requests in parallel. It doesn't wait for the result to the first get to > issue the second one. But it does do every get separately, i.e. it may > contact the same note multiple times. > > In theory we could do with at most one message to each node for each > multiget. We don't do it because it would actually require quite a bit of > change in the current code and it's unclear it would really buy us much. > Since we already parallelize requests, we would mostly win a bit on network > traffic (by merging messages) but there is good chance this is unsignificant > (of course I could be wrong given we haven't tried). > > -- > Sylvain > >> -- >> Filipe Gonçalves >> > -- Filipe Gonçalves
