From owner-freebsd-hackers  Tue May 21 07:27:43 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id HAA27945
          for hackers-outgoing; Tue, 21 May 1996 07:27:43 -0700 (PDT)
Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA27914
          for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 May 1996 07:27:31 -0700 (PDT)
Received: (from imb@localhost)
          by asstdc.scgt.oz.au (8.7.5/BSD4.4) id AAA11593
          Wed, 22 May 1996 00:26:24 +1000 (EST)
From: michael butler <imb@scgt.oz.au>
Message-Id: <199605211426.AAA11593@asstdc.scgt.oz.au>
Subject: Re: Netscape Proxy Server on FreeBSD
To: mark@quickweb.com (Mark Mayo)
Date: Wed, 22 May 1996 00:26:23 +1000 (EST)
Cc: angio@aros.net, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <Pine.BSF.3.91.960520235129.9352A-100000@scooter.quickweb.com> from "Mark Mayo" at May 21, 96 00:08:21 am
X-Mailer: ELM [version 2.4 PL24beta]
Content-Type: text
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Mark Mayo writes:

> Squids are setup with their 'parent' being a central HP/UX machie on the
> pipe out of the U (the parent server has 2GB of cache space). The setup
> works superbly, because each department usually is interested in the same
> sort of sites, and sites that aren't in the local neighbor's disk are sent
> to the main server.. all in all we estimate about 45% success on cache
> hits.

I have a similar experience .. putting my ISP hat on, I realised fairly
quickly that, if a simple lack of CPU and disk bandwidth wasn't going to get
me, then a limitation on the number of available file-descriptors would.

Netscape is configured by default to make four concurrent requests. The
cache (either Harvest or Squid) will inherit some to talk to a client and
some more when it finds a place to get the requested information (whether on
a peer, parent or the real origin). These can add up extremely quickly on a
busy cache .. if you leave the default of maxusers at 10, we have 180 file
descriptors .. divided by four .. you get the picture.

The "trick" that I've used in this instance is to use a single DNS name to
refer to multiple 'A' records, each pointing to a different "front-line"
host. These peer with each other and parent from one central machine.

Of course, if a peer (or parent) fails to respond within the mandated 2
second 'UDP ping time', a front-line cache will fall back to going direct
and the user's request still gets serviced.

The only problem is that some &^$* browsers cache the DNS information
resulting in far worse load imbalances than you might otherwise hope for :-(

	michael