Re: [squid-users] Clarification on delay_pool bandwidth restricting with external acls

I have similar configuration, the download of the user its not more
than 128 bytes, but the squid consume all the bandwidth.

squid 3.0 STABLE1

On Thu, Jun 7, 2012 at 6:43 AM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On 1/06/2012 2:20 p.m., Cameron Charles wrote:
>>
>> Hi all, im just after some clarification on using delay pools with
>> external acls as triggers, i have a good understanding of the
>> components of delay pools and how they operate but most documentation
>> only mentions users aka ip addresses as the method of triggering the
>> restriction, i would like to use an external acl to decide whether a
>> request should be limited or not regardless of any other factors, so
>> any and all traffic coming through squid, if a match to this acl, is
>> restricted to say 128bps, is this possible and is the following the
>> correct way to achieve this???
>>
>> acl bandwidth_UNIQUENAME_acl external bandwidth_check_ext_acl_type
>> UNIQUENAME
>> http_reply_access allow bandwidth_UNIQUENAME_acl !all
>> delay_class 1 1
>> delay_parameters 1 128.0/128.0
>> delay_access 1 allow bandwidth_128.0_acl
>> delay_initial_bucket_level 1 100
>>
>> additionally im a inexperienced when it comes to actually testing
>> bandwidth limits is it possible to simply download a file that is
>> known to be a match to the ext acl and observe that it doesn't
>> download at over the bandwidth restriction or is testing this more
>> complicated.
>
>
> Yes that is pretty much it when testing. Max download should be no more than
> 128 bytes per second according to that config.
>
> If that shows a problem the other thing is to set debug_options ALL,5  (or
> the specific delay pools, comm, external ACL and access control levels
> specifically) and watch for external ACL results and delay pool operations
> to see if the issue shows up.
>
> Amos
Received on Thu Jun 07 2012 - 13:31:20 MDT