On Tue, 10 Nov 1998, Henrik Nordstrom wrote:
> It is also not very likely that any cache will benefit from peering with
> more than at most 2 such servers for a given FTP site.
Right. However, the more FTP servers you peer with the better, and digests
allow you to avoid maintaining a "which mirror holds what" tables, a big
advantage.
> Building a cache digest of such a server requires both more work to code
> it up, and more CPU time and I/O to rebuild the digest.
The coding part is as complex/trivial as answering an ICP query, IMO. As for
the CPU, network and disk bandwidth, one can build a digest once per day,
when the load is small (or as a low priority bg job). The total impact will
be negligible (at most the impact of an ICP server running all the time).
> Another major drawback of cache digests applied here is that Squid does
> not yet handle false hits.
This is not a drawback of cache digests though. Eventually, Squid will handle
false hits. Also, the number of false hits for static data should be very
small (most of the false hits we get now are from dynamic/expired objects).
If we are talking about a one-night-stand fix, ICP is OK as a temporary hack;
not sure it is worth the trouble if there is a better alternative on the way.
Alex.
Received on Tue Nov 10 1998 - 14:59:44 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:42:59 MST