Re: squid-users-digest Digest V99 #205

Scott Hess wrote:
>
> On 4 Jun 1999, "Allen Smith" wrote:
> >On Jun 2, 7:18am, Reuben Farrelly (possibly) wrote:
> >> I guess one of the more important points to note is that for many if
> >> not most people, Squid is used primarily to *save* bandwidth and
> >> therefore cost.
> <snip>
> >Certainly. That's one of the points behind the below idea - the client
> >is almost certainly going to make the request anyway.
> >
> >> At Wednesday 2/06/99 04:32 AM -0400, Allen Smith wrote:
> >> >A minor version of this that wouldn't be nearly as hard to implement
> >> >(I've looked at doing it myself, although it's currently pretty far
> >> >down on my ever-growing list of tasks) would be requesting and caching
> >> >any cachable referred object (referred via HTTP responses, not HTML
> >> >coding).
>
> I'm not sure I follow. Prefetching should use strictly as much or more
> bandwidth, never saving bandwidth. At the limit, if all clients request

More. Only in the ideal case would the bandwidth used prefetching
objects equal the bandwidth used if you don't. It's _faster_ if they're
prefetched, but every short delivery, or link clicked by the user while
the page is still loading, or stop button pressed means that you
potentially fetched objects that went' unrequested.

So: Ideal case== no saving in bandwidth but faster. Other cases== more
bandwidth, and maybe or maybe not faster.

> all such objects, the bandwidth usage will be identical. But if any
> clients don't request all objects, bandwidth will potentially have been
> wasted. As far as bandwidth usage goes, it would seem to be a losing
> proposition.
>
> OTOH, I can't imagine doing such prefetching unless you have bandwidth to
> burn,

And you're not paying by the byte.

D
Received on Sat Jun 05 1999 - 00:21:55 MDT