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@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
