Miscellaneous questions

[Michael S. Fischer]

On Feb 13, 2008 7:41 AM, Dag-Erling Smørgrav <des at linpro.no> wrote:

> I believe varnishlog -w /var/log/varnish.log is enabled by default if
> you install from packages on !FreeBSD.  We may want to change this.

This was true for my RHEL 4 installation.  I was only able to achieve
16,000 connections/second after completely disabling logging to disk
(and fine tuning the thread pool size), which is why I asked my
question about further turning down the verbosity of logging to
memory.

> I think the default timeout on backends connection may be a little
> short, though.

I assume this is the thread_pool_timeout parameter?

> > > (3) Feature request: Request hashing.  It would be really cool if
> > > Varnish were able to select the origin server (in reality another
> > > Varnish proxy) by hashing the Request URI.  Having this ability would
> > > improve the cache hit ratio overall where a pool of caching proxies is
> > > used.
> > We have sort of given up on the peer-to-peer cache fetches using
> > dedicated protocols, but if you are able to tell that another
> > varnish is a better place to pick up something, nothing prevents
> > you from making that a backend of this varnish and doing
> > a pass on the request.
>
> No, I think what he means is selecting the backend based on client-ip
> modulo number-of-backends so each client always gets the same backend
> (which makes session tracking much easier)

That's a good idea, too, and deserves implementation, but I was
referring to something else.  I think phk understood what I was
getting at.

I'm dealing with a situation where the working set of cacheable
responses is larger than the RAM size of a particular Varnish
instance.  (I don't want to go to disk because it will incur at least
a 10ms penalty.)  I also want to maximize the hit ratio.

One good way to do this is to put a pass-only Varnish instance (i.e.,
a content switch) in front of a set of intermediate backends (Varnish
caching proxies), each of which is assigned to cache a subset of the
possible URI namespace.

However, in order to do this, the content switch must make consistent
decisions about which cache to direct the incoming requests to.  One
good way of doing that is implementing a hash function H(U) -> V,
where  U is the request URI, and V is the intermediate-level proxy.

I'd appreciate it if you'd consider adding this as a feature.

Best regards,

--Michael