RE: decreased caching efficiency?
William, Where does caching make sense? Static assets that can be stored on the edge closest to customers ie images, audio, video. These needs are served by your Akamais, IBeams, and Evokes. One other place where it makes sense to cache, in your Corporate environement. There will probably be a flux point for cost savings in respect to bandwidth if a company is able to get the majority of web traffic to remain on the LAN. But in regards to a caching architecture for your web site. Sites that have any revenue tied to advertising will benefit highly from knowing exact demographics, exact visitor counts, etc... In addition advertisers pay more for "targeted advertising" and targeted advertising is done with Dynamic technologies that can not be cached (the banner can be cached and await retrieval). Push technologies are to the advertising industry as napster is to the music industry. Acting as a catalyst in '96, the advertising industry recognized the benefit of targeted advertising that push technologies offer and embraced the internet. There are entire business models built on this principle (pioneers ADFORCE - formerly IMGIS, recent newbies alladvantage, mvalue, etc...). Commerce sites are also dependent on dynamic technology that cannot be cached. Although you will find sites that are entirely static (buy.com & etoys.com) you will generally find that these models are based on volume and that the majority of these sites have never seen a dollar in profit. However the profitable boutique type sites like eStyle.com, are entirely dynamic. Margins are protected by a contractual product line. When you place an order, a query verifies inventory prior to final checkout. In addition, product pages indicate whether items are in stock or not. You cant cache these types of sites. Granted this architecture is hard to scale, but they represent a rare breed of commerce vendors making cash. And by the way saving bandwidth is not justified for the majority of the market. 80% of deployed sites are sucking less than 2Mbps in monthly fees. Most caching implementations will cost way more than the bandwidth costs they avoid. Some dynamic site architectures will benefit from caching if the cache product is able to reduce the number of web servers required in a farm and/or if the cache engine working with the web farm is able to reduce the load on the DB servers. But TTLs will usually have to be set pretty low (2 seconds) in order to do this and the technologies will have to be catered to web development environments (like cacheflow and ASP). Travis Grant System Architect www.kore.com -----Original Message----- From: William Allen Simpson [mailto:wsimpson@greendragon.com] Sent: Friday, October 20, 2000 7:04 AM To: nanog@merit.edu Subject: Re: decreased caching efficiency? Dana Hudes wrote:
I vehemently disagree with the statement that impressions do not make any
sense,
only clickthroughs. There is such a thing as brand awareness, a situation where a banner ad is good for itself even if it doesn't lead to click through.
Of course, in that case, the benefit is to the advertiser. That is, they get the benefit, but you don't get paid. Not my problem. That seems to follow "not make any sense", but YMMV.
It is NOT for YOU to decide what business model makes sense for MY business relationship with MY advertisers.
Nope. You can have any business relationship you'd like. But, by the same token, it is not for *YOU* to decide that *I* have to pay to support YOUR business decision. Last time I looked, there's no constitutional right that guarantees that you can make money.
I pay my ISP to carry IP packets around.
But, you don't pay ME to carry your IP packets around. My customers pay me. I pay my upstream. Therefore, I pay my upstream as little as possible.
In some cases certainly your cache is in fact a copyright violation.
Interesting, if true. Perhaps you could provide a citation? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
On Fri, Oct 20, 2000 at 11:59:58AM -0700, Travis Grant wrote: [..]
Commerce sites are also dependent on dynamic technology that cannot be cached. Although you will find sites that are entirely static (buy.com & etoys.com) you will generally find that these models are based on volume and that the majority of these sites have never seen a dollar in profit. However the profitable boutique type sites like eStyle.com, are entirely dynamic. Margins are protected by a contractual product line. When you place an order, a query verifies inventory prior to final checkout. In addition, product pages indicate whether items are in stock or not. You cant cache these types of sites. [..]
Each and every button, product image etc could be cached, regardless of the dynamic nature of the website. Images cost cycles, bw. [..]
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. 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. That's why the CDN strategy is much more attractive, where you have a hosting relationship of some kind with the content origin. [..]
load on the DB servers. But TTLs will usually have to be set pretty low (2 seconds) in order to do this and the technologies will have to be catered to web development environments (like cacheflow and ASP). [..]
Hmm, if you cache what I suggest above, that's not really neccessary... No? Cheers, Chris -- Christian Kuhtz Architecture, BellSouth.net <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Atlanta, GA "Speaking for myself only."
[ 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 <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
[ On Friday, October 20, 2000 at 11:59:58 (-0700), Travis Grant wrote: ]
Subject: RE: decreased caching efficiency?
Where does caching make sense? Static assets that can be stored on the edge closest to customers ie images, audio, video. These needs are served by your Akamais, IBeams, and Evokes.
Certainly content distribution makes sense for really busy sites that have significant quantities of such content to distribute, but that's only the sending half of the picture. ISPs will continue to deploy transparent cache servers whenever they can justify the savings (be it in raw bandwidth costs alone, or in combination with softer savings in helping manage user expectations, etc.) When 10% efficiency at peak loads is 10% less bandwidth you buy and your bandwidth costs are high enough that 10% means a free mid-range server every month, you can afford to do a *lot* of caching. 10% of $2k/month isn't always a worthwhile savings given the potential costs of achieving it, but 10% of $25k/month makes the CFO take notice! Turn that into more like $80,000/month (as would be the case for an ISP on the far side of the globe that's trying to justify a fast low-latency terrestrial connection) and you'll really be seeing the full picture!
One other place where it makes sense to cache, in your Corporate environement.
Yup, though there the cache is just a free side-effect of running a proxy server that you've got to run in the first place. If you use Squid or some equivalent instead of just a raw NAT or other non-caching proxy server then all you need is a bit more disk and a bit more memory and you're instantly seeing at least some savings. Note that a transparent cache running in a corporate proxy server can usually get much higher savings than any such cache in an average ISP environment can get too (I've personally seen 50% on enough occasions to prove that it's actually reducing peak bandwidth needs by at lest 30%!). Not only that but remember that the corporate gateway cache can often be peered with the ISPs cache, further improving things noticably.... All this really means, BTW, is that cache-ignorant webmasters will be forced to learn or loose, and the more they learn the more we all save! So, yes, there might be a lot of newbie webmasters out there creating uncachable content these days, but they will be forced to learn that they're cutting off their noses to spite their own faces!
And by the way saving bandwidth is not justified for the majority of the market. 80% of deployed sites are sucking less than 2Mbps in monthly fees. Most caching implementations will cost way more than the bandwidth costs they avoid.
Not if you're a hosting provider and you aggregate those savings over many customers! :-) A pair of Squid machines running as accelerators in front of a farm of virtual hosting servers will work wonders at reducing the load on those back-end servers. You still charge your customers based on actual traffic out your pipe (from the squid logs), but now you can squeeze more small sites onto fewer bigger and more efficient (cheaper to run) servers. Furthermore since the savings granted by transparent caches at the last-hop provider (or corporate gateway) are literally "free" for the hosting provider, they're absolutely a major benefit! -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
participants (3)
-
Christian Kuhtz -
Travis Grant -
woods＠weird.com