We've been using memcached directly from our Perlbal instances for caching. We wrote a plugin to Perlbal that takes inbound URLs, does a tracker lookup to find a storage node, and then pulls the image from that node. We used an async memached client library we had written for an earlier project. We cache both lookups against our Mogile trackers and the images pulled from our Mogile storage nodes. We run a memcached instance and a Perlbal instance on each front end machine. We haven't posted this code any where, but we could publish if anyone is interested.
<br><br>Chris<br><br><div><span class="gmail_quote">On 10/9/06, <b class="gmail_sendername">Ask Bjørn Hansen</b> <<a href="mailto:ask@develooper.com">ask@develooper.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;">
<br>On Oct 9, 2006, at 18:07, Jake wrote:<br><br>> What is LiveJournal (or others) doing to serve up these<br>> dynamic-but-cachable requests efficiently? Are they just optimizing<br>> dynamic generation (memcached, etc) so it doesn't hurt so bad, and
<br>> buying additional servers?<br><br>Many of us have sites with pages that can be mostly, but not entirely<br>cached. Or sometimes the page can be entirely cached, but you need<br>to run a bit of logic to figure out which variant of the page is to
<br>be served (etc etc). Doing it in the backend is much easier to<br>scale than if you start adding too many smarts to perlbal.<br><br><br> - ask<br><br>--<br><a href="http://www.askbjoernhansen.com/">http://www.askbjoernhansen.com/
</a><br><br><br></blockquote></div><br><br clear="all"><br>-- <br><a href="http://avatars.imvu.com/chris">http://avatars.imvu.com/chris</a>