North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: decreased caching efficiency?
- From: Greg A. Woods
- Date: Fri Oct 20 18:05:01 2000
[ On Friday, October 20, 2000 at 15:14:10 (-0400), Christian Kuhtz wrote: ]
> Subject: Re: decreased caching efficiency?
> > Most caching implementations will cost way more than the bandwidth costs
> > they avoid.
> You get no argument there ;-). I never felt that you could ever justify
> caching in terms of bandwidth savings.
There's definitely a sweet spot on the graph, at least if you're in a
region where you actually pay real money for real bandwidth.
It's really hard to calculate the exact savings of a cache, but just in
watching Cricket graphs from the ones I operate I'm guessing that
there's at least a 15%, and sometimes 25%, savings in bandwidth based on
the difference between what the servers are requesting from upstream and
what they're delivering back to the clients downstream. Interestingly
this savings almost always is the most during peak loads. This can mean
up to $2500/month or more for even a relatively small ISP with peak
loads of say 50-60 requests per second, and that my friend can buy a lot
of hardware and consulting time when you accumulate it at the end of the
> You can only justify in terms of
> improving a users experience. And in that sense, you are giving considerable
> resources to a content origin, and a free service to them.
Yes, ABSOLUTELY! Another *HUGE* advantage is in helping to manage user
If you're a broadband reseller, particularly if serving any community
where people talk and compare experiences with each other, then having a
transparent cache can even out a lot of weirdness on the Internet and
though it might slow down the fastest things for power users sometimes
it'll also speed up many slow things for average users and in general
give everyone the same feeling for how "fast" things are on the WWW (and
that's almost all that counts these days).
One of the tricks with managing user expectations though is to always
have had a transparent cache and to attract users who really have no
alternative to IPS with transparent caches (i.e. it's a good idea to
convince your competitors to join in the caching game early too!). This
way user's don't usually know that the broken sites were never broken
and they complain to the cache-ignorant webmaster instead of to you! :-)
Eventually cache-ignorance will have to become a thing of the past,
regardless of what any webmasters think today -- once the Internet gets
*really* big there's no alternative but to dynamically and automatically
move content as close to the client as possible. Heck some blue sky
thinkers have even proposed putting transparent caching right in IP!
As you say all webmasters should all be hugely appreciative of the
resources that such last-hop providers provide on their behalf!
With appropriate routers and redundant cache machines the cost of
running transparent caches, both in real capital costs as well as in
support headaches with users trying to view broken sites, etc., is
well within the total savings of both bandwidth and poor user
perceptions. Of course it helps if you don't just buy brand new
equipment at MSRP..... :-)
The biggest problems we've had are with networking bugs in various
operating systems (both FreeBSD and NetBSD suffer similar bugs, though
I'm at least a release behind on both) which only show up under extreme
load -- i.e. right when it's really really bad for the machine to crash! :-)
I should really break my bad habit of not rebooting my big servers at
least once per week (though in one client's case even that wasn't
frequent enough). Other than that they basically just sit there and
hum along like any good hard-working appliance.
BTW, Personally I don't maintain any exception lists. Everything gets
cached, no if's, and's, or but's. Cache-ignorant webmasters be damned!
The only "exceptions" most of my clients have ever considered making are
to forcibly redirect users to the cache or another high-speed local
server for large and frequently accessed objects (such as a new software
download or whatever). However so far I've avoided even having to do
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>