java client locking issue

[Dustin Sallings]

On Apr 4, 2007, at 16:06 , Steven Grimm wrote:

> 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.

	Sure, sounds like a good plan.

> 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.

	I was hoping to add UDP support to my client, but my preliminary  
testing was a bit disappointing since multi-packet requests were  
rejected.

> 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.

	Ah, I didn't see a link to the svn repository from within the web  
site (found it going up a directory).

	Thanks for all the input.

-- 
Dustin Sallings


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