Re: What's the best configuration for this setup?

> > I noticed a particularly unpleasant problem I'd appreciate ANY input on,
> > and that is that when someone requests a page through our proxy, and it
> > is NOT cached, it checks the "parent". IF upstream has it, (and here's
> > the catch), it comes roaring down the 128K and consumes most of our
> > bandwidth while it does so. If it's a large file (big web page, or worse,
> > a large file that's being FTPd), this can go on for quite some time.
>
> This was discussed on freebsd-hackers not so long ago. It is possible to
> bandwidth limit connections by a simple
>
> while () {
> read();
> sleep();
> }
>
>
> If course, sleep(), or usleep() are not appropriate for squid, but how
> hard would it be to implement an algorithm which says "OK, I'm supposed
> to read max 3000 chars/sec; I just read 1500 chars; I must not read again on
> this connection for at lease 500 ms."??
>
> My guess is that it would need a bandwidth and an "earliest time for next
> read" to be stored for each (outbound?) tcp connection.
>
> One could also limit write()s so that delivery is throttled.

Limiting write() will not help if you don't have control of the upstream
proxy, so it would be better to control it at the receiver (IMO).

I've come up with a thought that may overcome the problem in MY case, and
may or may not be a more widely usable fix.

On my proxy, if I set a PPP link to the main host via RS232 (a 12"
cable), but set the RS232 link speed to 38K or 56K, set the route to the
upstream proxy to go via THAT interface, but the local users on the ethernet
port of the proxy, I can throttle by simply adjusting the RS232 speed.
Regardless of number of proxy hits, the main upstream link can't get
flooded if the RS232 speed is less than the uplink, but then that may not
be entirely ideal either. If _all_ traffic on the link at that time is
for the proxy, why _not_ let it have it all?
 
A complex, but perhaps ideal solution, would be to set thresholds on the
link. Tell squid it's allowed "X" Kb/sec minimum, but to "back off" if
link activity is high. This could be measured by parent response time
perhaps? For instance, we ping our upstream proxy in typically 35-40ms
under light load. If that suddenly blows out to 100-200ms, the link is
getting busy, and at 300+ it's getting flogged.

If squid could start throttling at say, 100ms and linearly drop to the
specified minimum at 300ms, I'd be wrapped. (These figures would need to
be site-selected).

Pipe dream?

RossW
Received on Fri Nov 22 1996 - 19:04:57 MST