Varnish ICP?

[Poul-Henning Kamp]

In message <20070518101851.F47501 at verden.pvv.ntnu.no>, =?ISO-8859-1?Q?Andreas_R
=F8sdal?= writes:

>> Our thinking on ICP in general is that a two-layer setup is a better
>> use of HW-resources.
>
>It would be interesting to know a little more about how to configure 
>Varnish in a two-layer setup. I guess this would be of interest to others 
>deploying varnish as well.

Sorry about the delay, I've been travelling for most of the last week.

Right now, I don't know of anybody who has created a two-layer
Varnish setup, so most of what we have on the table is conjecture.

The overall argument against a peer protocol is that peer servers
are unlikely to have to document we are looking for, simply because
this machine doesn't have it.  We see the same probabilities for
the documents on all servers.

The reason why this argument comes out the other way for squid, is
that squid's peer facility were built for the case where the real
object were behind a slow and expensive WAN line, whereas asking
the peer is just a high-speed trip across the LAN.  In the time it
took to establish a TCP connection across the WAN we could ask all
our peers and even if the probability of a hit was very low, a hit
saved us precious WAN time.

In our case the only benefit is a minute reduction in backend load
and a longer delay for all transactions that eventually goes to the
backend after the peer check.

Hold this up against the implementation of a pretty nasty protocol
with a lot of state and a geometric increase in activity on all
involved Varnish machines, and the benefit is hard to spot.

Compare this to setting up a two-level Varnish:

	frontends --- concentrator --- backend

If any of the frontends have document X, it is also on the
concentrator, so instead of asking N frontends to find it,
we are guaranteed to get it by asking the concentrator.

And, more importantly, if the concentrator does not have it,
it will pick it up from the backend for us.

In other words, we need no extra code, there are no "blind alleys"
for the request and overall performance will better.

Obviously, this all pressumes that the concentrator has the hardware
it needs, but if you are in the bandwidth class where you have this
problem, a 64GB RAM machine is probably not going to shock you.

But as I said, this is all conjecture and handwaving, but I'm pretty
sure it holds up.

Obviously, if your dataset is enormous, things may not look
this way and other ways to skin this rhubarb may be necessary.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.