Cache-as-cache-can

Tue Nov 17 02:18:22 UTC 1998

We performed a number of tests with most all the vendor's 
products.  Considering that most all the vendor's are represented on this 
list, I do not want to get into a p*ssing contest on a public list as to who 
has the best cache.

We found important a number of items to consider with Web Caching.

1) Accuracy.  If the served page is not the requested page, your 
customers will let you know.

2) Transparency.  As long as your customers don't care it's there then 
everything is okay.  When a Web Cache hangs up and black holes your Web 
traffic, that's a bad day.  There are some layer 4 switches out in the 
marketplace (Foundry and Alteon) who redirect Web requests and run port 
80 keepalives.

3) Availability.  You don't want a sub-tera Web Cache subject to a single 
disc failure.  Layer 4 switches also take care of your Web Cache cluster 
keeping flows and content contiguous.

4) Performance.  There are a number of factors including max sessions, 
access speed and a few others to consider.  Bottom line is that Web 
performance is a perceived service and is often subjective.  

5) Also realize that Web Caches do interesting things in switched 
networks where 60-75% of your traffic belongs to a single IP address.  
Equal cost IGP metrics avail nothing.

6) The goal of Web Caching is not to reduce line utilization.  We found 
some cases where line utilization maxed when we added the Web Cache.  
Having a 100Mbps box proxying all Web traffic can seriously expand TCP 
Windows as opposed to a typical modem which introduces serialization delay.

Our goal was to give better international Web performance to customers 
while also making the most intelligent use of the international resources 
by removing redundant information.  Interestingly enough, we also have 
seen a reduction of 20% TCP retransmissions to less than 2% on the core.

-eric

On Tue, 17 Nov 1998, Katsuhiro Kondou wrote:

> In article <19981116200208.A27675 at magnet.at>,
> 	Michael Haba <m.haba at magnet.at> wrote;
> 
> } To cut a long story short, I was just wondering if people could extrapolate 
> } their feelings regarding commerical Web Cache solutions. In terms of the
> } good, the bad and the ugly.
> } 
> } At the moment I'm left with 'two goods' Network Appliance's NetCache and
> } Inktomi's Traffic Server and would appreciate some input to sort them out.
> 
> I don't think there is major difference in caching, but some
> appliance have some problem in their routing. NetCache learns
> it from icmp redirect or rip1 which is quite poor for redundant
> network topology.  I don't know about CacheFlow quite well, but
> it seems to speak rip1 at most.  I believe they should speak
> ospf at least, if they run in a large isp.  As for inktomi,
> there may not be any routing problem since it runs on some unix
> boxes, but it cannot handle so many connections simultaneously
> like NetCache or CacheFlow.
> -- 
> Katsuhiro Kondou
> 