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@magnet.at>, Michael Haba <m.haba@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