non-blocking IO in clients (and other questions)

[Brian Aker]

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/                     <-- Me
http://tangent.org/                <-- Software
http://exploitseattle.com/    <-- Fun
_______________________________________________________
You can't grep a dead tree.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20071002/f09dca0c/attachment.htm