> > 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 > > Assuming one server and binary protocol... a single write to the socket > would be made for both keys under both the binary and ascii server > (assuming the keys are small enough to fit into the default buffer, > which is the case assuming trunk version of memcached). > > The code bunches up as many requests as can be made into the buffer > before flushing. When looking through the code I didn't find anything > that should be fouling that up (though I did find that we were > incrementing the packet counter more then what we should, but that won't > really effect anything).
Both keys go out okay, but the no-op at the end seems to go out in a separate packet. I've noticed this on several installs using libmemcached, verified with tcpdump/etc. (in his case it's just one server he was testing against). -- --- 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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
