<br>We have seen latency on the memcached server end in one scenario: large multi-gets from other clients. Due to a bug part of our application was occasionally generating a 10,000+ key multi-get. This caused other clients to see pauses while the memcached server handled that request.
<br><br>Other than that we see no significant latency.<br><br>Chris<br><br><br><br><div><span class="gmail_quote">On 4/19/07, <b class="gmail_sendername">Steven Grimm</b> <<a href="mailto:sgrimm@facebook.com">sgrimm@facebook.com
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Lexington Luthor wrote:<br>> memcached is certainly not causing your performance problem. Both java
<br>> and ruby have garbage collectors which can cause huge latency problems<br>> particularly if every 30ms matters to you. I don't know about ruby but<br>> java's GC can not be turned off in your code, so you will likely have
<br>> GC-related latency problems. Some VM language implementations e.g.<br>> CPython will let you turn off the GC though.<br><br>On a multi-CPU machine, I'd recommend switching to Java's concurrent<br>garbage collector, which in most cases basically eliminates long GC
<br>delays. It does cost more total CPU time than the non-concurrent<br>collectors but it makes things much smoother.<br><br>What does CPython do if you turn off GC? Does the process just keep<br>getting bigger and bigger until the machine runs out of memory? Python
<br>used reference-counting internally last I looked; if you turn off<br>garbage collection, how does it ever free up objects with circular<br>references? Or do you just have to be careful not to create circular<br>references in that case?
<br><br>-Steve<br><br></blockquote></div><br><br clear="all"><br>-- <br><a href="http://avatars.imvu.com/chris">http://avatars.imvu.com/chris</a>