non-blocking IO in clients (and other questions)

Brian Aker brian at
Tue Oct 2 16:36:34 UTC 2007


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.


Brian "Krow" Aker, brian at
Seattle, Washington                     <-- Me                <-- Software    <-- Fun
You can't grep a dead tree.

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the memcached mailing list