On 3/01/2013 6:03 a.m., Nick Rogers wrote:
Hi,
I have a question concerning delay pools and upload bandwidth control.
I know in the past with squid 2.x and earlier 3.x versions, it was not
possible to restrict upload bandwidth (squid requests to web servers)
using delay pools.
However, now there is a feature that is new to me, client delay pools,
which appears to insert bandwidth buckets between a client and squid.
Can someone please explain the difference between the old delay pools
feature and the newer client delay pools directive? As I understand,
the old delay pools affects traffic between a remote webserver and
squid, and the new client delay pools affects traffic between squid
and the client. I am curious what the different primary use cases are
between the two.
The primary use-case is upload vs download traffic. The server pools
restrict what gets read from the server. The client pools restrict what
gets read from the client. Write restrictions are still dependent on TOS
/ QoS setup.
And finally, is there now a way to limit upload rate using squid,
where upload is from the perspective of the client (e.g., end-user
uploading a file to a webserver)?
No. more correctly it is end-user uploading to Squid which is limited.
Large uploads which are short-circuited by HITs, server connection
errors, auth challenges, or ICAP/eCAP rejected have large amounts of
traffic which only gets delivered to Squid and then dropped.
Amos
