java client locking issue

[Steven Grimm]

Dustin Sallings wrote:
> I measured a considerable improvement in the initial version of my 
> implementation with a single thread over the multithreaded 
> implementation.  I'll go ahead and try adding multiple connections per 
> destination and see if it makes a difference.

I'd be perfectly willing to believe the other implementation is just not 
as efficient as yours. Please try using multiple connections; I'm sure 
everyone here would be curious to hear the results.

> Does that really give a considerable performance benefit over running 
> four single-threaded processes on the same box?  I'd be concerned 
> about locking (and correctness) on the server-side.

For small-scale installations, the difference is probably not too 
significant. But in our case, we see significant gains in two areas. By 
running 1/4 the number of processes, we quadruple the chances of a large 
"get" request wanting multiple objects from the same instance, and a 
two-key "get" is far more CPU-efficient than two one-key requests. 
Second (though this is mitigated to a large extent by using a UDP-based 
client) we only have 25% as much memory devoted to I/O buffers, 
including kernel socket buffers. And in addition to those gains, it is 
also easier for our operations people to manage one process per box than 
four.

As for locking and correctness, please feel free to audit the code; the 
locking should be pretty easy to follow. We are running it on about 150 
high-traffic dedicated memcached hosts right now and it has been stable 
and (as far as we know) error-free for us, but of course it's always 
possible there are bugs.

> Is there any documentation on how this branch uses threads?  It'd be 
> an interesting read.

doc/threads.txt has some information about the implementation. It is a 
very conservative implementation; the code can be compiled as a 
single-threaded application by leaving out a single -D option on the 
compiler command line, in which case the execution paths are nearly 
identical to the 1.2.x code base.

It would be possible to do more major surgery, of course, if one were 
willing to give up the option of compiling it single-threaded. And even 
without giving that up, there are some obvious changes that could be 
made to decrease lock contention (see the "TO DO" section in 
doc/threads.txt). But the current implementation is sufficient for our 
setup.

-Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070404/25618963/attachment.html