> On Feb 18, 2013, at 6:03 PM, Diogo Baeder <[email protected]> wrote: > > > I have no clue why libmemcached does that switch in the middle, but I > > understood what you said about not expecting things to happen in an exact > > order > > Are you sure the data is on the same server? Libmemcached responds back with > whatever returned first, which when spread across a number of servers,... > well who knows who might respond back the quickest. > > If you want order, then issue a single blocking get (one after another).
That's not quite what he meant. He's seeing: 1) libmemcached requests 2 keys 2) memcached responds with 1 key 3) libmemcached sends no-op packet 4) memcached responds with 2nd key, no-op packet This is just due to the test being run over localhost. libmemcached sends the final no-op packet in a second write, so memcached has a chance to start responding before receiving it. If libmemcached sent everything as one write he probably wouldn't have noticed until testing with much larger multigets. It's not a problem, it's just not what he was expecting I guess? The only "actual" problem here is both libmemcached and memcached generating a nonoptimal amount of syscalls and wire packets. -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
