Re: [squid-users] Will Delayed Pools to help with squid fetching content?

From: Jose Ildefonso Camargo Tolosa <ildefonso.camargo_at_gmail.com>
Date: Mon, 26 Jul 2010 15:27:22 -0430

Hi!

On Fri, Jul 23, 2010 at 8:31 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> Etienne Philip Pretorius wrote:
>>
>> Hello List,
>>
>> I am running Squid Cache: Version 3.1.3. and I wanted to cache windows
>> updates and applied the suggested settings from
>> http://wiki.squid-cache.org/SquidFaq/WindowsUpdate but now I am experiencing
>> another problem.
>>
>> It seems that while I am able to cache any partial downloaded files with
>> squid now, I am flat-lining my break out onto the Internet. I just wanted to
>> check here before attempting to implement delayed pools. As I see it, it is
>> squid fetching the file at maximum speed possible.
>>
>> So my question is, if I implement delayed pools for the client connections
>> - will squid also fetch the files at those reduced rates?
>
> Not directly. Squid will still fetch the files it has to at full speed.
> However, indirectly the clients will be delayed in their downloads so will
> spread their followup requests out over a longer time span than without
> delays.

I remember and old thread about a similar situation: it was a person
who was trying to use squid for an ISP, but subscriber connections are
a lot slower than ISP's connection to the Internet, and so: when a
client started a download for a 600MB file, squid would fetch the
whole file using a lot of bandwidth, and the client would not even be
at 10% of the download, so.... if the client decided to cancel the
download at say, 25%, there would be a lot of wasted bandwidth.

Can that situation be corrected with delay pools? or, what do you need
to correct that? The desired behavior is that squid actually follows
the download at the speed of the fastest client!, instead of its
connection to the Internet.

What do you think?

Sincerely,

Ildefonso Camargo
Received on Mon Jul 26 2010 - 19:57:29 MDT

This archive was generated by hypermail 2.2.0 : Tue Jul 27 2010 - 12:00:04 MDT