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.
