<div class="gmail_quote">On Fri, Jan 15, 2010 at 5:33 PM, pub crawler <span dir="ltr"><<a href="http://pubcrawler.com">pubcrawler.com</a>@<a href="http://gmail.com">gmail.com</a>></span> wrote:</div><div class="gmail_quote">
<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Varnish performs very well.  Extending this to have a cluster</div>
functionality within Varnish I think just makes sense.  </blockquote><div><br></div><div>haproxy and F5 equipment also both perform very well.  </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The workaround<br>
solutions so far seem to involve quite a bit of hardware as well as<br>
having a miss rate of 50% in example of 2 Varnish instances.  Sure it<br>
can hot populate fast, but it's two stacks of memory wasted for the<br>
same data per se.</blockquote><div><br></div><div>If you hash your requests from a load balancer across a pool of n varnish instances, the most you lose in the event of a failure is 1/n.  You don't cache objects in more than one instance.  There's no "wasted" memory. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> I suppose a custom solution to hash the inbound<br>
requests somehow and determine which Varnish should have the data can<br>
be done, but unsure if anyone now is doing that.<br></blockquote><div><br></div><div>That's precisely what L7 switches do.  As David said, haproxy has this functionality, as do other implementations.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Squid is a total disaster.  If it wasn't none of us would be here</div>
using Varnish now would we :)  It's amazing Squid even works at this<br>
point.<br></blockquote><div><br></div><div>Can you quantify this statement?  Squid works very well at some installations.</div><div><br></div><div>It's not like the code that was out there working spontaneously started to become buggier. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I put in a feature request this evening for this functionality.  We'll<br>
see what the official development folks think.  If it can't be<br>
included in the core, then perhaps a front-end Varnish proxy is in<br>
order developmentally.  I'll say this akin to Moxi in front of<br>
memcached instances: <a href="http://labs.northscale.com/moxi/" target="_blank">http://labs.northscale.com/moxi/</a></blockquote><div><br></div><div>I'm all for putting backend hashing into Varnish for the purpose of routing requests to backends based on a consistent hash of the request parameters -- and there's no reason why the backend can't be another Varnish instance.  But the appropriate use of this is to more efficiently utilize cache memory by associating an object with a designated Varnish server in a pool, not for HA.  This was one of my first requests that still (alas) has seen no traction.</div>
<div><br></div><div>--Michael</div></div>