Transparent Caching Solutions - Information Wanted

Tue Feb 3 15:38:41 UTC 1998

> I'm looking at the various transparent caching solutions available as
> per Cisco's Cache Engine.
> 
> Can anyone tell me of any other products that work in a similar
> (transparent) manner and any experiences with these ?

We make one called the Web Gateway Interceptor, which we distribute through
the fine folks at <URL:http://www.mirror-image.com/>.  A handful of folks on
the NANOG list have tried it or are running it now, with varying degrees of
success.

Network Appliance's <URL:http://www.netcache.com/> is planned to be offer
transparency at some point but I'm not sure whether the high-performance
cache box (based loosely on their NFS server appliance) they're shipping
actually has transparency right now or not.  NetCache is Peter Danzig's
"Commercial Harvest" by a new name.  Peter works for NetApp now.

Inktomi <URL:http://www.inktomi.com> has announced their intention to offer
transparency but they are not an appliance (like Cisco, Vixie, and NetApp)
and last I heard they were waiting on some Solaris kernel changes before
they could actually ship transparency.

Transparency turns out to be really, really hard from an HTTP level.  When
you're a transparent cache none of the normal HTTP rules apply to you -- or
sometimes more than one conflicting rule applies to you.  At times you are
a client, at other times you are an origin server, and rarely, you are a
proxy.  We've had to use our customers' log files and complaints over the
last year or so to figure out a set of rules which minimize complaints.  At
the moment they also tend to minimize hit rates compared to our earlier
product, but we're working on that.

One thing to note about caching in general is that the page splay is too wide
for any single cache to do you much good.  Multilevel caching, in the style
of the ICP projects such as Harvest and NLANR, is the only way to get reason-
able (reasonable means "50% or higher") cache hit rates in real production.
Multilevel caching depends on moderate sized primary caches (~10GB) sharing
access to a larger (~500GB) secondary cache.  A single primary cache (say for
example, a transparent cache in front of 1000 modems) won't see enough query
duplication before purge rollover to make its hit rate really interesting.