Guess what: I just built a fake Memcached server, to answer hardcoded values (same as before) to a get_multi op for pylibmc, with normally ordered batches (2 reqs, 1 noop, 2 resp, 1 noop), and it worked. So, in the end, it seems like forcing the ordering is not what is causing me troubles, it's something else that is failing to me that I didn't yet notice. In other words, libmemcached seems to play just fine with ordered batches.
Not sure if this adds anything here, but I thought you might want to know. :-) Cheers! __________________________ Diogo Baeder http://diogobaeder.com.br On Tue, Feb 19, 2013 at 12:15 AM, Diogo Baeder <[email protected]>wrote: > Yep, agreed, Dormando, not a problem, just different from my initial > expectations. I'll just have to figure out how to use Tornado in my favor, > to build this part, and deal correctly with the asynchronicity. :-) > > Cheers! > > __________________________ > Diogo Baeder > http://diogobaeder.com.br > > > On Tue, Feb 19, 2013 at 12:11 AM, dormando <[email protected]> wrote: > >> > 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. >> >> >> > -- --- 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.
