non-blocking IO in clients (and other questions)

[Mikael Johansson]

Hi,

In short, non blocking io allows you to send and receive data on
multiple sockets at the same time, without having to use threads. This
makes sense if you have multiple servers and are batch-fetching keys,
batch modifying keys or pipelining requests (ie. sending the next
request without waiting for the response to the previous.)

The other issue could be that you don't check how much data from the
write was actually accepted into the network buffer and then try to
write additional data which overflows and thus overwriting your key. You
might try concatenating the whole request into a single write which will
also keep the request in a single packet if its small enough.

//Mikael

Brian Aker wrote:
> Hi!
> 
> So I am looking at increasing the performance in libmemcached. Looking
> at how some of the other clients are implemented I am finding a catch-22
> that I am hoping someone can explain.
> 
> Most clients seem to be setting their IO to non-blocking, which is
> excellent, but I don't understand what this is really buying since:
> 1) Clients are not threaded
> 2)  The protocol always sends an ACK of some sort.
> 
> Take "set" for example. I can do a "set" which is non-blocking, but then
> I have to sit and spin either in the kernel or in user space waiting for
> the "STORED" to be returned. This seems to defeat the point of
> non-blocking IO. 
> 
> I must be missing something about the above, since I can't see why there
> is a benefit to dealing with non-blocking IO on a set, if you will just
> end up waiting on the read() (ok, recv()).
> 
> On a different related note, I've noticed another issue with "set". When
> I send a "set foo 0 0 20\r\n", I have to just send that message. I can't
> just drop the "set" and the data to be stored in the same socket. If I
> do that, then the server removes whatever portion of the key that was
> contained in the "set". Maybe this is my bug (though I can demonstrate
> it), but that seems like a waste. AKA if on the server its doing a
> read() for the set and tossing out the rest of the packet then its
> purposely causing two roundtrips for the same data.
> 
> Looking through all of this, I am hoping that the binary protocol, which
> I eagerly await reading, has a "set" which doesn't bother to tell me
> what the result of the "set" was. You could pump a lot more data into
> memcached if this was the case. 
> 
> Cheers,
> -Brian
> 
> 
> --
> _______________________________________________________
> Brian "Krow" Aker, brian at tangent.org
> Seattle, Washington
> http://krow.net <http://krow.net/>/                     <-- Me
> http://tangent.org <http://tangent.org/>/                <-- Software
> http://exploitseattle.com/    <-- Fun
> _______________________________________________________
> You can't grep a dead tree.
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://lists.danga.com/pipermail/memcached/attachments/20071002/0e201444/signature.pgp