<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Apr 4, 2007, at 16:06 , Steven Grimm wrote:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">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.</FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>Sure, sounds like a good plan.</DIV><BR><BLOCKQUOTE type="cite"> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">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.</FONT></P> </BLOCKQUOTE></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>I was hoping to add UDP support to my client, but my preliminary testing was a bit disappointing since multi-packet requests were rejected.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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.</DIV></BLOCKQUOTE></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>Ah, I didn't see a link to the svn repository from within the web site (found it going up a directory).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>Thanks for all the input.</DIV><BR><DIV> <SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV>-- </DIV><DIV>Dustin Sallings</DIV><BR class="Apple-interchange-newline"></SPAN> </DIV><BR></BODY></HTML>