[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squid-users
Subject:    [squid-users] =?utf-8?b?IFNwZWVkIOKAi+KAi2xpbWl0IGZyb20gZmlsZSBz?= =?utf-8?q?ize?=
From:       Amos Jeffries <squid3 () treenet ! co ! nz>
Date:       2018-06-21 5:44:36
Message-ID: ba3982fc-0b50-3b81-1011-81ee5a1200ed () treenet ! co ! nz
[Download RAW message or body]

On 21/06/18 21:44,  Michael Pro wrote:
> Is it possible to limit the speed of receiving the file to the client
> depending on the file size?

NP: HTTP has no concept of "file". There are only messages. A message
may contain 0 or more *pieces* of those things we humans call "files".


> Let's say,
> file =<1MB client download with 400Kbit/s
> file 1MB...5MB client donload with 4Mbit/s
> file >5MB - no speed limit
> 
> I try fore some settings
> delay_pools 1
> delay_class 1 2
> delay_access 1 allow storeid_app_2
> delay_access 1 allow storeid_app_6
> delay_access 1 deny all
> delay_parameters 1 -1/-1 50000/1000000
> delay_parameters 1 -1/-1 500000/5000000
> delay_parameters 1 -1/-1 -1/-1

NP: each repetition of delay_parameters *replaces* previous settings for
that pool #1. The above spend lots of CPU calculating bandwidth for the
related requests, but does nothing.


> ...
> but it does't work
> 
> Can some method take place to solve this problem?


To receive the message at full speed into Squid, then dole it out slowly
to clients use the client_delay_* directives. The ones above only affect
read's from servers.
 <http://www.squid-cache.org/Doc/config/client_delay_parameters/>

Secondly, you need a different pool for each speed limit. The *_access
controls determine which transactions get which pool(s) speed limit
applied to them.


That said, there is almost no way to know how big an object is going to
be until it has finished arriving. What gets transmitted can be
compressed, split into ranges, chunked as a stream rather than a single
object or any combination of the above.

The best that can be done is checking Content-Length from the reply
message headers - *IF* the reply message even has one. Relevance and use
of that header is declining as dynamic content grows in popularity.


I recommend looking into OS level QoS controls and applying more general
bandwidth shaping instead. That way it does not matter what a client is
doing, if they are doing a lot of it they wont impact others on the
network quite as badly as uncontrolled traffic flow.

Amos
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[prev in list] [next in list] [prev in thread] [next in thread]