non-blocking IO in clients (and other questions)

[Brian Aker]

Hi!

On Oct 2, 2007, at 9:49 AM, Mikael Johansson wrote:

> 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

I see that, but I am not seeing where in the drivers multiple sockets  
are being created. It could be and I am just not finding them. Plus  
most of the code I am seeing written is pretty procedural in nature.  
Make a request and ask or a response. Non-blocking won't buy you  
anything but perhaps a few instructions between the send() and the  
recv().

Even with multiple sockets you can't do much with this unless you  
wrap the object so that you create something of a "multiple_set()".  
For get I have done that, its really the nature off the code to do this.

> 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.

Yep, though if the code is all waiting on a response this doesn't  
make much of a difference either.

Cheers,
	-Brian

>
> //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.
>>
>>
>

--
_______________________________________________________
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/586b4623/attachment.htm