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.
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.
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.
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
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.
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.
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.