C.2 Configuring Squid

Before you can use delay pools, you must enable the feature when compiling. Use the ”enable-delay-pools option when running ./configure . You can then use the following directives to set up the delay pools.

C.2.1 delay_pools

The delay_pools directive tells Squid how many pools you want to define. It should go before any other delay pool-configuration directives in squid.conf . For example, if you want to have five delay pools:

 delay_pools 5 

The next two directives actually define each pool's class and other characteristics.

C.2.2 delay_class

You must use this directive to define the class for each pool. For example, if the first pool is class 3:

 delay_class 1 3 

Similarly, if the fourth pool is class 2:

 delay_class 4 2 

In theory, you should have one delay_class line for each pool. However, if you skip or omit a particular pool, Squid doesn't complain.

C.2.3 delay_parameters

Finally, this is where you define the interesting delay pool parameters. For each pool, you must tell Squid the fill rate and maximum size for each type of bucket. The syntax is:

 delay_parameters   N     rate   /   size   [   rate   /   size   [   rate   /   size   ]] 

The rate value is given in bytes per second, and size in total bytes. If you think of rate in terms of bits per second, you must remember to divide by 8.

Note that if you divide the size by the rate , you'll know how long it takes (number of seconds) the bucket to go from empty to full when there are no clients using it.

A class 1 pool has just one bucket and might look like this:

 delay_class 2 1 delay_parameters 2 2000/8000 

For a class 2 pool, the first bucket is the aggregate, and the second is the group of individual buckets. For example:

 delay_class 4 2 delay_parameters 4 7000/15000 3000/4000 

Similarly, for a class 3 pool, the aggregate bucket is first, the network buckets are second, and the individual buckets are third:

 delay_class 1 3 delay_parameters 1 7000/15000 3000/4000 1000/2000 

C.2.4 delay_initial_bucket_level

This directive sets the initial level for all buckets when Squid first starts or is reconfigured. It also applies to individual and network buckets, which aren't created until first referenced. The value is a percentage. For example:

 delay_initial_bucket_level 75% 

In this case, each newly created bucket is initially filled to 75% of its maximum size.

C.2.5 delay_access

This list of access rules determines which requests go through which delay pools. Requests that are allowed go through the delay pools, while those that are denied aren't delayed at all. If you don't have any delay_access rules, Squid doesn't delay any requests.

The syntax for delay_access is similar to the other access rule lists (see Section 6.2), except that you must put a pool number before the allow or deny keyword. For example:

 delay_access 1 allow TheseUsers delay_access 2 allow OtherUsers 

Internally, Squid stores a separate access rule list for each delay pool. If a request is allowed by a pool's rules, Squid uses that pool and stops searching. If a request is denied, however, Squid continues examining the rules for remaining pools. In other words, a deny rule causes Squid to stop searching the rules for a single pool but not for all pools.

C.2.6 cache_peer no-delay Option

The cache_peer directive has a no-delay option. If set, it makes Squid bypass the delay pools for any requests sent to that neighbor.