|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: decreased caching efficiency?
[ 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 year! :-) > 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 expectations. 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 that.... -- Greg A. Woods +1 416 218-0098 VE3TCP <[email protected]> <robohack!woods> Planix, Inc. <[email protected]>; Secrets of the Weird <[email protected]>
|