<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On May 10, 2007, at 14:58 , Steve Grimm wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">On 5/10/07 11:09 AM, "Dustin Sallings" <<A href="mailto:dustin@spy.net">dustin@spy.net</A>> wrote:</DIV> <BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space"> </SPAN>No, I don't wait, but with a single connection to memcached (where "single"</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">may be substituted with a small number), requests naturally stack up and can</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">be merged.<SPAN class="Apple-converted-space"> </SPAN>Write buffers can pull from all queued events.<SPAN class="Apple-converted-space"> </SPAN>Reducing the</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">number of packets moved around the network for requests would seem like it</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">should increase performance.</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Yes, absolutely it will, both from a server CPU point of view (multi-get is</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">much more efficient than get) and, if you're really pushing a lot of</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">traffic, from a network capacity point of view. So you're saying the</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">batching only happens when the socket buffer on your memcached connection is</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">full and you have to hang on to data and wait for the connection to become</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">writeable again anyway? That makes sense. (Yes, sorry, I know I could just</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">go look at the code...)</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>Right. I'm a bit lazier in this than I could be (partially because buffers in java are...weird), but effectively, the IO thread maintains its own write buffer that it fills from buffers from other operations. There's a special case in the fill method that merges sequential gets.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>Even without the get merging, multiple requests to the same server may be sent in the same packet.</DIV><BR><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I think it isn't something we ever considered because the ratio of number of</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">memcached hosts to number of client processes on any single client machine</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">here is pretty high; the chances of enough separate client processes on one</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">host needing to write enough requests to the same memcached host at the same</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">time to clog up a connection are pretty slim. But if your number of clients</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">per host is much higher than your number of memcached servers, then that</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">wouldn't be so true.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>This makes sense. In a java app server context like mine, I'd get very little benefit from such a thing because I'm already able to share the connection resource very effectively. I'm thinking more about the cases where people aren't able to.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>You seem to have your farm well under control.</DIV><BR><BLOCKQUOTE type="cite"> <BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space"> </SPAN>It's interesting that you tried this.<SPAN class="Apple-converted-space"> </SPAN>Do you still have the proxy</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">application available?<SPAN class="Apple-converted-space"> </SPAN>It may be a good starting point for my experiments,</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">and it may not be as optimal as what I'm thinking.</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">We do still have it, and the plan from the start was to release it as open</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">source at some point. Since it ended up being less useful than we thought it</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">would be, I didn't finish the prep work for that. It still needs a bit of</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">cleaning up (not to mention documentation) before I'd be comfortable</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">unleashing it on the world. If people are really interested I'll see what I</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">can do, but don't expect it tomorrow or anything.</DIV></BLOCKQUOTE></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>Well, don't worry about the state of it too much, but take your time. I'm not in a huge hurry to take on more work now anyway.</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>