Re: bandwidth spikes

On Thu, 28 Jan 1999, Gideon Glass wrote:

> Folks,
>
> Some of our Cobalt CacheRaQ customers running various Squid 2 versions
> are seeing some strange bandwidth spikes. I'm wondering if anyone
> else has seen these problems and if there's a solution (or if not
> where to start hacking for a solution).

[snip]
 
> During a spike, what seems to be happening is that Squid downloads one
> or more large HTTP objects very rapidly. In one ~2 second interval,
> tcpdump showed ~380KB on one TCP connection from a remote server to
> squid. In the same interval a single dialin client got ~15KB on its
> connection from the cache.

I raised this about 18 months ago, and to the best of my knowledge, there
has been little if any work done on it. In my part of the world, bandwidth
is *much* more expensive than many other places, and massive pipes are
simply not viable. Thus, when a dial-up customer at say, 28K8, requests a
large file through squid, and especially if that file is at a well
connected site (say, in the proxy at an upstream provider), squid will
suck the file down ASAP. This has many detrimental side effects, including
general degradation of the link to all other (local) network users.

I put forward an idea that I'd like to see some throttling of squid to
suck data at only marginally higher rate than the client is taking the
data. So, someone with a 14K4 modem pulling a 30Mb file, does NOT NEED
squid to pull that 30Mb file at maximum rate and kill your link, it simply
needs to pull at something a little over 14K4. If someone else comes and
starts pulling the same file, suck harder to keep up with them (if
possible). Perhaps, rather than trying to match bandwidth, squid could
simply "read ahead" by some arbitary amount - enough to keep the client
fed flat out, whilst being "nice" to the available bandwidth.

I have not looked into the code to see how difficult this would be, but if
said quickly, it seems to be pretty straight-forward. Rather than fetching
as fast as possible, fetch only when the read-ahead buffer is under the
threshold value.

RossW
Received on Sat Jan 30 1999 - 18:47:11 MST