[31780] in North American Network Operators' Group
Re: decreased caching efficiency?
daemon@ATHENA.MIT.EDU (Dana Hudes)
Fri Oct 20 11:05:04 2000
Message-ID: <00c201c03aa6$cc786bc0$3d5cdcd1@hudes.org>
From: "Dana Hudes" <dhudes@hudes.org>
To: "Ian Cooper" <icooper@equinix.com>
Cc: <nanog@merit.edu>
Date: Fri, 20 Oct 2000 11:02:42 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Errors-To: owner-nanog-outgoing@merit.edu
Ian
----- Original Message -----=20
From: "Ian Cooper" <icooper@equinix.com>
To: "Dana Hudes" <dhudes@hudes.org>
Cc: <nanog@merit.edu>
Sent: Friday, October 20, 2000 10:33 AM
Subject: Re: decreased caching efficiency?
> At 09:44 10/20/00 -0400, Dana Hudes wrote:
>=20
>=20
> And browsers implementing caches in memory or disk are also causing=20
> copyright violation. Yet for the most part browser caches are =
considered a=20
> Good Thing.
No and yes. The user has a license to display the image on their screen =
for as long
as they keep the browser window open on the page . Browser cache is good =
for user because
they may scroll or resize the window and don't have to fetch.
>=20
> >In general I do not want people to have my photos stored in their =
browser=20
> >cache (much less permanently saved).
> >I do actually have plans to change around some things in my site to =
take=20
> >advantage
> >of browser and network caching (e.g. putting the style sheet in a =
separate=20
> >file,
> >ditto the JavaScript and any other constant information I can).
>=20
> And that saves practically nothing, given that they're very small=20
> files. Your choice, of course.
True. The hope is somehow though to save processing the files not just =
transferring.
>=20
> >When I switch to CGI-based delivery of images the cache will of =
course=20
> >become pass-through
> >since there will be no file to cache just a stream of bytes....
>=20
> Is the assumption there that by using CGI you'll automatically tweak a =
> configuration in a caching proxy? If so then it's a flawed =
assumption.
>=20
But there is no file to cache? I don't have enough gear to set up a test =
with squid myself
(and that would only be one cache) but how is the engine to know to =
cache it?=20
My understanding is that CGI-generated content is usually not cached.
>=20
> Having had a very quick look at your site, it seems a little strange =
that=20
> you want to defeat caching of those objects that soak up bandwidth; =
the=20
> request to perform "click-through" on the advert suggests that you're =
using=20
> the revenue to pay for your bandwidth costs. (So, one assumes that =
the=20
> more the material was cached, the less you'd have to pay, and the less =
> you'd have to worry about page impressions.) I particularly like the =
way=20
> that you require my browser to send a Referer field to be allowed to =
view=20
> the pictures ;-)
I do indeed use the revenue to pay for bandwidth but the pictures, by =
and large
(its a work in progress) have been tuned for file size; still takes time =
to decompress but hey,
what can I do. Also the projected load vs. the bandwidth is such that I =
have a LOT more room left. The users get a reasaonbly large bitmap in a =
reasonably small file. ImageMagick is nifty set of programs. The =
problem I have is pirates who collect images and use them for other =
purposes.
the pictures...well, I actually don't want them hanging around on the =
user's disk once the browser is no longer on the page.
I haven't figured out how to make that happen other than expiration of 1 =
minute or something.
I'm working on a system for managing/publishing photo web sites like =
mine. It will be released as free software when I get it all working =
satisfactory and
maybe I'll write some documentation.
>=20
> Nice photos though...
Thanks.=20
You do point out that while I pay fixed cost for bandwidth (my server is =
behind a DSL circuit) others might use the technology to host where they =
pay for usage as it occurs. An quandary.
