non-blocking IO in clients (and other questions)
brian at tangent.org
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 tangent.org
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...
More information about the memcached