java client locking issue
dustin at spy.net
Wed Apr 4 23:41:56 UTC 2007
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
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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the memcached