Best Java client ?

[Roy Lyseng]

Henrik Schröder wrote:
> Hi Dustin,
> 
> Out of pure curiosity, have you benchmarked the difference between your 
> single-connection client and a comparable multi-connection one with a 
> connection pool?
> 
> And have I understood it correctly that the reason your version is as 
> fast as or faster than a multi-connection one because memcached in 
> itself is single-threaded and will process requests in a serialized 
> fashion anyway?

Not answering on Dustin's behalf, but...

Well, the memcached server itself has just turned multi-threaded...

However, the memcached single-threaded server is indeed very fast, and 
mostly because there is no context-switching or waiting within the 
server loop. It will simply receive a request, process it and send back 
a response.

This works very well as long as the server CPU is very fast. However, if 
the CPU cannot cope with the load, both throughput and latency will 
suffer. So in order to service e.g. a 10GbE network, multiple CPU 
threads and parallel processing may be required to keep up with the 
speed of the network. But the challenge is not only with the memcached 
user threads. The networking stack must also be sufficiently 
parallelized, and/or being able to batch requests within the kernel layer.
> 
> 
> /Henrik
> 
> On Wed, May 7, 2008 at 11:02 PM, Dustin Sallings <dustin at spy.net 
> <mailto:dustin at spy.net>> wrote:
> 
> 
>     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
> 
>