On May 7, 2008, at 12:00, Roy Lyseng wrote:
Anybody having benchmark data to back up this?
It depends quite a bit on how you benchmark it.
My client has *very* little contention, so the number of client
threads doesn't bother it so much. If you have a lot of threads
accessing stuff randomly, it should work better. If you have 100
threads asking for the same key simultaneously, my client will make
two requests, decode the value twice, and dispatch it to all the
requestors. I don't expect that to be a common case, but multi-gets
are faster than multiple individual gets, so the general case for
multi-get escalation is made. Deduplicating the keys was just easy
while I was already doing it.
Similarly, all but a few operations are completely asynchronous to
the client, so sets return roughly immediately in all cases, so you
never have to wait for one unless you actually want to know whether it
was successful. Same for gets. You can request some data at the
beginning of the method, do some other stuff, and then use it in the
middle once it may have arrived.
On the other hand, I'm not currently doing a good job of utilizing
available CPUs to decode results from multiple requests. There are a
few easy workarounds for this, but I'm hoping to provide something
directly for it.
Also, I only open one connection to the server, so TCP congestion
avoidance algorithm isn't cheated (which seems to be desirable for
some people). This can be worked around in some of the same ways as
the above (the easiest way currently is to have a couple of active
clients), but it's not a desirable way to do things. I'm hoping to be
able to clear more of this up in my ``three'' branch.
Of course, patches and bug reports are welcome for anything that
doesn't perform as well as it should.
--
Dustin Sallings
