Strategies for splitting load across varnish instances? Andavoiding single-point-of-failure?
w at 1wt.eu
Thu Jan 28 14:37:57 CET 2010
Poul-Henning Kamp <phk at phk.freebsd.dk> wrote :
> >Let's get back to consistent hashing and it's use...
> >Correct me if I am wrong, but doesn't this mean that adding a new
> >varnish instance implies a full rehash ?
> Yes, that is pretty much guaranteed to be the cost with any
> stateless hashing.
No, not with the consistent hashing algorithm. This is a very
interesting technique. The hash is not as well distributed as
common hash algorithms, but each new server only takes one
small part of other server's job. If a server goes down, its
job is redistributed on other ones without the other ones'
jobs being redistributed.
Please read here for more info :
This has been implemented in haproxy precisely for caches. You can
enable it in any backend by simply specifying "hash-type consistent".
Moreover, you get the benefit of the slowstart feature, which means
that a server may be progressively reintroduced into the farm during
a warm up period instead of taking a big hit at once when it's seen
Someone asked about the advantages of hashing URLs for caches. It's
simple, it's just to optimise requests placement : send a request to
the cache that is the most likely to already have fetched the same
object and have it in cache. Do that while monitoring your network
bandwidth. I think you'll observe a reduction when switching from
anything to url_hash.
Hoping this helps,
More information about the varnish-misc