Re: DELAY_POOLS: How to setup

From: Martin Bene <[email protected]>
Date: Thu, 12 Nov 1998 23:24:12 +0100

At 18:08 11.11.98 +0200, you wrote:
>Well, I think that delay pools is one of the most useful features of Squid,
>addressed to manageable teams of users, so I will try to give a brief
>explanation of how it works.

Thanks a lot!

I've been trying to get delay pools to work all day; (reason: a single user
soaked up my complete bandwidth for a few hours by starting several
downloads of 76MB files from microsoft simultaneously, often canceling
after about half..)

however the results aren't really usable at the moment;

For testing purposes let's just set a limit of 6K/second for individual
clients:

delay_class1_access deny all
delay_class2_access allow net-dialup
delay_class2_individual_max 6000
delay_class2_individual_restore 6000

Now let's try it out.

1) Start downloading a big file (2MB) from a nearby server -> OK, as
expected the file is transfered at 6K/second.

2) While this transfer is active, try to open a few small web pages, also
on nearby server.

Hoped-for reaction: the available bandwidth of 6k is shared more or less
evenly between the outstanding requests.

Observed reaction: the big download keeps running at 6k/sec and no other
requests get serviced at all until the big one finishes.

This obviously isn't very useful since normal user behaviour is to keep
browsing around while a large upload is in the works; is this a problem
with my configuration or inherent in the delay_class implementation?

Ultimately, I'd like to set a fairly large maxvalue (say, 1MB) and just
brake single clients to ISDN speed or a little higher for larger files.
That way there should be no actual slowdown for dialup-users while still
preventing large files to hog all available bandwidth.

Platform is linux 2.0.35, Squid 2.1-pre3

Another question: how does delay-class on proxy A impact clients connected
to proxy B, if A is the parent cache of B? Are prox B's ICP requests reated
just as if it was a normal client?

Thanks for any insights on my problems.

Bye, Martin
--------------------------------------------------
 Martin Bene vox: +43-664-3251047
 simon media fax: +43-316-813824-6
 Andreas-Hofer-Platz 9 e-mail: mb@sime.com
 8010 Graz, Austria
--------------------------------------------------
finger mb@mail.sime.com for PGP public key
Received on Thu Nov 12 1998 - 15:22:09 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:43:02 MST